Anatomy of a USPS Phishing Campaign: Google-Authenticated Delivery, Rotating Hosts, and Real-Time Backend Control

Postal-themed phishing is nothing new. What made this campaign worth examining was not the lure itself, but the infrastructure and workflow behind it.

The delivery email passed SPF, DKIM, and DMARC as google.com. The email-linked URL routed visitors through a stable redirector to changing final hosts. During testing, the phishing content was reachable through residential egress, while tested datacenter-originating requests were redirected to google.com. The final application also used an encrypted Socket.IO / Engine.IO WebSocket channel that appeared capable of supporting real-time victim-state tracking and backend-controlled workflow changes.

This article walks through the observed chain from email delivery to the phishing backend. All URLs are defanged. Unless otherwise noted, conclusions are limited to the email, JavaScript, HAR data, browser observations, and live-site behavior reviewed during the investigation.

The email

The lure was a conventional USPS-themed “Delivery Exception Notice.” It claimed that a parcel with a tracking number ending in 9566 could not be delivered because of “Delivery Failed – No Access.” The recipient was told to update delivery preferences or reschedule delivery within 48 hours to avoid package return and a possible storage or return fee.

The message used two elements that could make it appear more credible:

• A genuine USPS logo loaded from www.usps.com
• A visible sender address of no-reply@google.com

The call-to-action link, “Click Here to Fix Delivery and Resume Shipment,” pointed to:

hxxps://deerhuntings[.]icu/TylerBaker7651

The message authenticated as Google

The visible google.com sender initially appeared likely to be a simple spoof. The authentication results showed otherwise.

SPF       Pass    google.com; sender IP 2607:f8b0:4864:20::349
DKIM      Pass    d=google.com; signature verified
DMARC     Pass    action=none; header.from=google.com
CompAuth  Pass    reason=100

The receiving platform treated the message as authenticated mail from google.com. The observed header chain included:

Received: from rso-3723509943153957537-c-gea1.us-east1.4.apigee.com
 (60.119.231.35.bc.googleusercontent.com. [35.231.119.60])
 by gmr-mx.google.com with ESMTPS ...

Message-ID: <...JavaMail.apigee@rso-3723509943153957537-c-gea1>

These fields are consistent with a JavaMail-based application associated with a Google Apigee hostname submitting the message through Google-hosted infrastructure. The observed submission host resolved within googleusercontent.com at 35.231.119.60.

This does not establish the attacker’s true origin. It does, however, show that the campaign used a Google-hosted delivery path that resulted in valid google.com authentication at the receiving platform.

The practical lesson is that SPF, DKIM, and DMARC indicate whether a message is authorized for a domain; they do not establish that the message is benign. Controls heavily weighted toward sender authentication or provider reputation may assign lower risk to a malicious message when the sending service itself is abused.

Detection therefore needs to consider the full context:

• Message content
• Embedded URLs
• Relay and submission path
• Brand mismatch between a google.com sender and a USPS-themed body
• Domain age and reputation
• Redirect behavior

In the artifacts reviewed, the external-sender warning was the principal visible caution presented to the recipient.

The recipient mail platform also recorded a minimum-domain-age value of:

deerhuntings.icu#96

This appears to indicate that the domain was approximately 96 days old at the time of delivery. A relatively recent domain age is consistent with short-lived campaign infrastructure, although domain age alone does not establish malicious intent.

The redirector

The email-delivered URL appears to function as a redirector or campaign gate rather than the final phishing page:

hxxps://deerhuntings[.]icu/tylerbaker7651

The initial URL remained stable, while the final destination changed across visits.

One observed visit resolved to:

hxxps://tkpnql[.]icu/JustinPeters2598/?__eat=6bbce411008440a5

A later visit through the same initial URL reached a different final host:

jmkfxu[.]icu

Both final hosts served substantially similar USPS-themed phishing content. These observations provide direct evidence that the stable redirector was capable of routing visits to more than one final host.

The path components such as /tylerbaker7651 and /JustinPeters2598/ may represent campaign, victim, route, lure, or generated tracking identifiers. Their exact purpose was not established from the available artifacts.

The email used mixed-case pathing:

/TylerBaker7651

The live analysis also observed:

/tylerbaker7651

This suggests the redirector may normalize or otherwise accept path casing, but the precise behavior should not be assumed without broader testing. Hunting should account for both forms.

Likely operational advantages

Although the operator’s intent cannot be proven from redirect behavior alone, this design could provide several benefits:

• Keep the email-delivered URL stable while changing final hosts
• Replace or abandon final domains without modifying messages already delivered
• Route visitors by IP, geography, user agent, fingerprint, time, cookie state, or campaign rule
• Reduce exposure to scanners, sandboxes, and takedown crawlers
• Assign visitors to campaign-specific or operator-specific workflows

Access gating and anti-analysis behavior

During testing, the phishing content was served when accessed through residential egress. Tested datacenter-originating requests were redirected to google.com and did not reach the phishing pages.

This behavior is consistent with server-side network-type, ASN, or IP-reputation gating. The available evidence does not establish which specific classification method was used, and other factors such as geography, cookies, fingerprinting, or prior-visit state may also have influenced the response.

The operational effect is significant. Many URL scanners, cloud sandboxes, crawlers, and analyst systems originate from datacenter networks. Redirecting those visitors to a benign destination can reduce automated visibility while still allowing likely residential users to reach the phishing flow.

For validation of similar infrastructure, analysts should consider testing from more than one network type and should avoid concluding that a site is benign based on a single datacenter-originating request.

The phishing application

Once the content was reached, the observed flow contained three primary stages.

Stage 1: Tracking lure

/a_index.html

The first page imitated USPS Tracking. It displayed a weather-alert banner, a tracking number, an “Out for Delivery” status, an address-verification problem, and a “Request Redelivery” call to action.

Observed tracking number:

9505556249179352689361

Stage 2: Personal-information collection

/b_info.html

The second page presented a “Delivery Address” form requesting:

• First name
• Last name
• Email address
• Phone number
• Country
• Street address
• Apartment or suite

The page also stated that photo identification would be required for collection from a Post Office, which may have been intended to make the request appear routine.

Stage 3: Payment-card collection

/c_pay.html

The third page presented a “Quick Payment” flow and claimed that a $0.99 redelivery fee was required because of an address discrepancy.

The form requested:

• Card number
• Expiration date
• Security code
• Cardholder name

The page displayed branding for Visa, Mastercard, American Express, JCB, Discover, and Diners Club.

The nominal fee appears to have served as a pretext for collecting full payment-card information.

Page naming varied across observed or analyzed deployments. The live host used:

/a_index.html
/b_info.html
/c_pay.html

The JavaScript-analyzed instance also referenced routes including:

/index
/phoneCode
/emailCode
/pinCode
/appCode
/tempCustomCode
/expressCvv

This suggests that route naming may differ between deployments of the same or related kit.

Real-time WebSocket communication

The frontend opened a Socket.IO / Engine.IO WebSocket connection to:

wss://tkpnql[.]icu/console/?uuid=<victim_uuid>&EIO=4&transport=websocket

No browsable administrative interface was observed at /console/. In the captured traffic, that path functioned as a Socket.IO / Engine.IO communication endpoint.

The HAR showed an HTTP 101 Switching Protocols response and an Engine.IO open frame:

{
  "sid": "...",
  "upgrades": [],
  "pingInterval": 5000,
  "pingTimeout": 10000
}

Normal Engine.IO keepalive frames were also observed:

2 = ping
3 = pong

This confirms that the endpoint accepted a WebSocket upgrade and exchanged Engine.IO control traffic during collection.

The final phishing host was proxied through Cloudflare. The HAR did not expose the true backend IP. A serverIPAddress value of 192.168.100.1 appeared in the capture, but that is an RFC1918 private address and is more consistent with a local gateway, proxy, VPN path, or capture artifact than attacker infrastructure.

Encryption provided limited protection against client-side analysis

The WebSocket messages and browser storage values used AES-CBC with PKCS#7 padding.

The relevant key and IV values were embedded in the delivered JavaScript:

Because these values were present in the client-side code, captured WebSocket data and browser storage values could be decrypted by an analyst with access to the JavaScript.

Decrypted traffic included a server-to-browser configuration message:

{
  "event": "userSiteConfig",
  "data": {
    "money": "",
    "successUrl": "",
    "currencySymbol": "",
    "products": []
  }
}

It also included browser-to-server state reporting:

{
  "event": "changleField",
  "data": {
    "router": "..."
  }
}

The event name changleField appears to be a misspelling and may be a useful kit-specific hunting string.

An additional message was observed:

{
  "event": "changleField",
  "data": {}
}

No victim PII, payment-card data, OTP, PIN, password, or other submitted sensitive data was present in the specific HAR capture reviewed.

Backend-controlled step-up capability

The JavaScript referenced several follow-on routes:

/phoneCode
/emailCode
/pinCode
/appCode
/tempCustomCode
/expressCvv

These routes appear intended to collect:

• SMS or phone OTPs
• Email verification codes
• Card PINs
• Banking-app approval responses
• Custom verification values
• American Express CVV values

The code also referenced backend workflow states including:

rejected
rejectedCode
waitVerificationPhone
waitVerificationEmail
waitVerificationPin
waitVerificationExpressCvv
waitVerificationApp
waitVerificationCustomCode
completed
success

Together, these artifacts are consistent with a backend-controlled phishing workflow capable of changing the victim’s page or requested information during a session.

The evidence does not prove that a human operator was actively controlling the specific session captured. It does support the assessment that the backend could direct victims into different verification flows, potentially under operator control.

This architecture could support real-time fraud activity in which submitted card details are tested and the victim is then prompted for a corresponding OTP, PIN, app approval, or other challenge. That use case is consistent with real-time OTP interception and step-up verification phishing, but it was not directly observed in the reviewed capture.

Data-collection capability

The JavaScript referenced fields associated with several categories of victim data.

Personal information

firstName
lastName
fullName
address
city
state
zipCode
phone
email
ssn
birthday

Payment-card information

cardHolder
cardNumber
expiryDate
cvv

Verification and step-up data

code
pin
customCode
customCode1
customCode2
expressCvv
account
password
confirmedApp
notReceivedApp
resendCode

The exact fields presented to any individual victim may vary by deployment, campaign configuration, card type, backend decision, or operator action.

The available collection surface could support payment-card fraud, identity theft, account compromise, and attempts to defeat step-up verification.

Client-side anti-automation

The primary JavaScript contained checks for multiple automation and headless-browser indicators.

Examples included:

HeadlessChrome
selenium
webdriver
puppeteer
playwright
cypress
nodriver
undetected

Additional artifacts included:

__webdriver_evaluate
__selenium_evaluate
$cdc_asdjflasutopfhvcZLmcfl_
$wdc_
_phantom
__nightmare
callPhantom
__playwright__binding__
__puppeteer_evaluation_script__

The application also contained fingerprinting logic involving:

• WebGL
• Canvas
• Audio
• Fonts
• Emoji rendering
• Media devices
• WebRTC
• Battery status
• Permissions API
• Chrome runtime behavior
• Workers

The combination of client-side automation checks and observed network-based gating would likely reduce the chance that a basic sandbox or crawler receives the same content as a residential user with a conventional browser.

Indicators and hunting artifacts

The indicators below are separated by confidence and operational use. Provider-owned or shared infrastructure should not be treated the same as confirmed malicious campaign infrastructure.

High-confidence malicious infrastructure

deerhuntings[.]icu
tkpnql[.]icu
jmkfxu[.]icu

Observed URLs and paths

hxxps://deerhuntings[.]icu/TylerBaker7651
hxxps://deerhuntings[.]icu/tylerbaker7651
hxxps://tkpnql[.]icu/JustinPeters2598/?__eat=6bbce411008440a5
wss://tkpnql[.]icu/console/?uuid=<uuid>&EIO=4&transport=websocket

/TylerBaker7651
/tylerbaker7651
/JustinPeters2598/
/a_index.html
/b_info.html
/c_pay.html
/console/
/index
/phoneCode
/emailCode
/pinCode
/appCode
/tempCustomCode
/expressCvv

Observed loaded assets

BEaJxlwt.js
CJjEG3KW.js
C9Lg4Na1.js
CVIEK_kr.css
gS0Gah9-.css

Kit-specific strings

changleField
userSiteConfig
waitVerificationExpressCvv
waitVerificationCustomCode
VERIFICATION_STATE
t_form_data
t_config

AES key and IV strings

ZQMWLSPXJRDHKTNV
YFBCUENAGPQLXJWR
NLFRWBHXVQJTCPYK
DMAGSZEIOPQUNTVC

MD5-derived storage keys

t_config
2e14a1ac17c37597f4579a51c5f26330

t_form_data
6677b6f7dd5ca11774f0f0e484baa3c0

VERIFICATION_STATE
ddafc76f38596c8b6769b63034d43f1d

router
f3395cd54cf857ddf8f2056768ff49ae

JavaScript SHA-256 hashes

Browser or RUM-related code
e1ac4849b9d4a498b68f8aca01e6ed99a11d94b35a2cec533b3916b8fb722fd6

Bundled framework and dependencies
e6d5449ff52125009b6cb10113b28275a1a61cc7c61adf2ddaa4ab6bb9ebbb8c

Primary phishing application logic
e374aeef6b5ca5f66cc43133fe70c82c8458c791f1e113b59d83bc7ec5ee35cc

Contextual delivery infrastructure

The following values were observed in the delivery path but belong to Google or other shared-provider infrastructure. They should not be blocked or treated as independently malicious without supporting context.

Observed From address:
no-reply@google.com

Observed Apigee-associated host:
rso-3723509943153957537-c-gea1.us-east1.4.apigee.com

Observed Google Cloud egress IP:
35.231.119.60

Observed reverse DNS:
60.119.231.35.bc.googleusercontent.com

Observed Google relay:
gmr-mx.google.com

These values are most useful when combined with:

• USPS-themed subject or content
• The identified redirector domains
• Matching Message-ID patterns
• Similar body links or paths
• Comparable Apigee and JavaMail header characteristics

static.cloudflareinsights[.]com was also observed as a loaded third-party resource, but it is legitimate Cloudflare infrastructure and should not be treated as a campaign IOC by itself.

Detection ideas

The following are platform-neutral hunting concepts. Field names and syntax will require adaptation to the local SIEM, proxy, DNS, email, or endpoint schema.

DNS, proxy, and firewall hunting

destination.domain IN (
  "deerhuntings.icu",
  "tkpnql.icu",
  "jmkfxu.icu"
)

url.path IN (
  "/TylerBaker7651",
  "/tylerbaker7651",
  "/JustinPeters2598/",
  "/console/"
)

WebSocket hunting

destination.domain = "tkpnql.icu"
AND url.path = "/console/"
AND url.query CONTAINS "EIO=4"
AND url.query CONTAINS "transport=websocket"

destination.domain IN ("tkpnql.icu", "jmkfxu.icu")
AND url.path = "/console/"
AND http.response.status_code = 101

Mail-flow hunting

Search for messages that combine several of the following:

• no-reply@google.com
• USPS-themed subject or body content
• Apigee-associated Received headers
• JavaMail and Apigee characteristics in the Message-ID
• Links to deerhuntings[.]icu
• Paths matching /TylerBaker7651 or /tylerbaker7651

The Google IP address, sender address, and Apigee hostname should not be used as standalone block indicators because they are associated with shared provider infrastructure.

Key takeaways

1. Authentication success does not equal message trust

This message passed SPF, DKIM, and DMARC as google.com. That result showed that the message was authenticated for the observed sending domain. It did not establish that the content or embedded destination was safe.

2. The stable redirector supported multiple final hosts

The same email-delivered URL routed to at least two different final hosts serving similar USPS-themed content. This design can improve campaign resilience and complicate blocking or takedown efforts.

3. Network context affected what the site served

During testing, residential egress reached the phishing content while tested datacenter egress was redirected to google.com. Analysts should avoid judging similar hosts from one network perspective alone.

4. The frontend supported real-time backend control

The observed WebSocket endpoint, route inventory, workflow states, and decrypted messages are consistent with a phishing application capable of victim-state tracking and backend-directed verification prompts.

5. Shared infrastructure must be handled carefully

Google, Apigee, Cloudflare, and other provider-owned infrastructure appeared in the campaign chain. These values are useful as contextual evidence, but treating them as standalone malicious IOCs would create false positives and could lead to overblocking.

This assessment is based on artifacts available at the time of analysis. Phishing infrastructure, routing logic, hosted content, certificates, DNS records, and provider assignments can change rapidly. Observations should therefore be validated against current telemetry before operational action is taken.