Inside a Fake DHL Campaign Built to Steal Credentials

X-Labs recently identified a consumer-targeted DHL phishing campaign that uses familiar brand impersonation, a fake OTP verification step and client-side credential harvesting to steal passwords from everyday users.

The campaign targets individuals rather than specific organizations and shows no geographic concentration. What makes it worth examining is the OTP mechanic: a trust-building layer with no real authentication behind it, engineered entirely to lower the victim's guard before the actual theft begins.

The sample analyzed here walks the victim through a spoofed shipment email, a fake parcel OTP page and a DHL-branded login portal. The final stage captures the victim's password, enriches it with IP address, device details and location data, then exfiltrates everything through EmailJS to an attacker-controlled mailbox.

A Lightweight Kit with an 11-Step Attack Chain

What makes this campaign effective is not sophistication, it's the structure. The full chain unfolds as follows:

• Email lure
• DHL brand impersonation
• Fake parcel OTP page
• Client-side OTP generation
• Fake verification step
• URL-based victim identity injection
• Fake DHL login
• Credential theft
• Victim profiling and telemetry collection
• Exfiltration via EmailJS
• Redirect to legitimate DHL site

This is a lightweight phishing kit designed to maximize user trust while minimizing attacker infrastructure overhead.

Stage 1: The Lure Arrives as a Spoofed Shipment Notice

The attack begins with a phishing email masquerading as a DHL express message:

Fig. 1 - Lure email

At first glance, the message is designed to appear as a logistics-related request for waybill or shipment confirmation. That theme aligns directly with the follow-on fake web workflow. The email uses the display name DHL EXPRESS, but the envelope/from domain is cupelva[.]com. This is an immediate mismatch. A legitimate DHL message would not normally originate from an unrelated domain.

Fig. 1.5 - DKIM check

While investigating the email header, it becomes clear that the message likely passed DKIM for cupelva[.]com, not for DHL. This matters because a DKIM pass can make the message look more legitimate to a filtering system or analyst who only examines authentication status without considering domain alignment. In other words, the message may be technically authenticated, but it is still malicious because it is authenticated as the attacker-controlled domain, not as DHL.

Stage 2: A Fake OTP Page Manufactures Trust

After the user clicks the link — hxxps[://]perfectgoc[.]com/aacggh/OTPWITCALLER[.]html?email=[victim@example[.]com] — they encounter a parcel-themed OTP interface:

Fig. 2 - Fake OTP page
 

This page is designed to look like a shipment validation step. It is not a real OTP mechanism. The verification interface is shown below:

Fig. 3 - Fake OTP page content
 

The page generates a six-digit number locally in JavaScript:

Fig. 4 - Client side OTP generation
 

This is not real verification. The code is generated on the client side, without any server interaction. There is no authentication backend, no SMS or email delivery and no actual identity validation. The victim is being asked to repeat a number already displayed on the screen.

Why the fake OTP step exists

This step serves no authentication function. It exists to manipulate the victim's perception of the workflow. Specifically, it does three things:

• Creates an illusion of security. A verification step signals that the system is protecting the user, even when no real verification is occurring.
• Builds user trust. Completing a step the victim believes is legitimate makes the next step — a login form — feel like a natural continuation rather than a threat.
• Legitimizes the overall flow. Multi-step processes feel more credible than single-page attacks. The OTP page borrows that credibility without any of the underlying infrastructure.

Artificial delay to mimic processing

The page waits two seconds before displaying the OTP section:

Fig. 5 - Artificial delay
 

This is a classic social engineering technique. The delay makes the page feel as though something is being verified in the background. In reality, nothing is happening. The pause exists only to reinforce the illusion of a working system.

URL-based identity handling

The code includes a helper designed to carry a value across redirects. The comments refer to it as a "tag," but the implementation uses an email parameter. The extraction of the victim identity from the hash or query string is shown below:

Fig. 6 - Extracting identity hash or query
 

The page obtains a victim identifier from either the URL hash fragment (e.g., #victim@example.com) or an existing query parameter (e.g., ?email=victim@example.com).

Carrying the email forward

When the victim moves to the next page, the email address is preserved in the URL. This allows the attacker to:

• Personalize the next stage
• Display the victim's email without asking for it again
• Create the illusion that the workflow already knows the user's identity

Fig. 7 - Carrying email forward

 

Redirect to the second-stage page

When the OTP matches, the user is redirected to the second-stage page. 

The destination host and path strongly suggest disposable or compromised infrastructure rather than legitimate DHL-owned services.

Stage 3: A DHL-Branded Login Page Harvests Passwords

The second page — hxxp[://]biotechgroup[.]net/… — is where the actual theft happens. It presents a DHL-branded interface with shipment-themed messaging, a preloaded email address, a password field and a "Confirm & Login" button:

Fig. 8 - Credential harvesting page
 

This is deliberate impersonation designed to make the victim believe the shipment is real, the account is already recognized and only one final confirmation is needed. The interface is not just imitating a brand, it is imitating the workflow.

Password harvesting

The only thing the victim is required to enter is a password.

That is a major red flag. A parcel verification page should not need the victim's account password. This confirms the page's real purpose: credential theft.

Victim telemetry collection

Before exfiltrating the credentials, the script gathers environmental data to enrich the stolen record.

IP address retrieval

The phishing kit cycles through multiple services to obtain the victim’s public IP address.

Device and browser fingerprinting

The script infers device type, operating system and browser family:

Geolocation lookup

Using the IP address, it attempts to derive approximate geographic information such as city, region and country. Additional metadata captured includes:

• Timestamp
• Full page URL
• Tracking number

This telemetry helps the attacker triage high-value victims, distinguish real users from automated scanners and support secondary fraud or account takeover efforts.

Local storage persistence

The kit stores the captured record in local browser storage.

This may serve as a backup mechanism and is not the primary exfiltration path. Either way, legitimate sites do not store submitted passwords in local storage for shipment confirmation workflows.

Stage 4: Stolen Data Exits Through a Legitimate Email Service

The most revealing section is the EmailJS configuration:

Fig. 9 - EmailJS config setting
 

The kit initializes EmailJS and sends the captured data using the configured service and template. The attacker mailbox is slatty077@tutamail[.]com. 

Exfiltration call

The templateParams object stores the full victim telemetry payload.

EmailJS is a legitimate client-side service. Attackers abuse it because it allows phishing kits to operate entirely in the browser, reduces infrastructure overhead and makes development faster and cheaper.

Stage 5: A Redirect to the Real DHL Site Closes the Loop

After submission, the page redirects the victim to the legitimate DHL site. 

Fig. 10 - DHL site redirect
 

This is a classic anti-suspicion step. The victim may believe:

• The login worked.
• The process completed.
• The prior pages were part of an authenticated DHL workflow.

Redirecting to the legitimate brand site after credential theft reduces the chance of immediate reporting.

Conclusion

Phishing does not need technical sophistication to succeed. This campaign works because it feels ordinary. The DHL branding is familiar, the verification step looks legitimate and the login form appears to confirm something the victim already started. None of it is real.

The OTP page builds trust. The credential harvesting page spends it. The fake verification step, the artificial delay, the URL-carried identity and the EmailJS exfiltration all serve the same goal: keep the victim moving forward without triggering doubt.

No malware. No complex backend. Just a sequence of familiar-looking pages, a legitimate third-party service repurposed for exfiltration and a final redirect to the real DHL site to prevent immediate suspicion. When a shipment-themed page asks for a password, threads identity through the URL and ships data to a third-party service, it is not confirming a delivery. It is stealing credentials.

Protection Statement

• Stage 2 (Lure) – Email delivered with a weaponized URL. Email is blocked.
• Stage 3 (Redirect) – Fake OTP URL domain is categorized.
• Stage 4 (Exploit Kit) – Credential harvesting URL domain is categorized.
• Stage 7 (Data Theft) – Attacker mailbox is blocked.

IOCs