Inside a Fake DHL Campaign Built to Steal Credentials
By Hassan Syed Faizan, X-Labs Senior Security Researcher
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 envelope/from domain is cupelva[.]com. This is an immediate mismatch. A legitimate DHL message would not normally originate from an unrelated domain like above. While investigating the email header, it becomes clear that message likely passed DKIM for cupelva[.]com, NOT for DHL.
This matters because DKIM pass can make the message look more legitimate to filtering system or analyst who only look at 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/spoofed/compromised domain, not as DHL.
Stage 2: A Fake OTP Page Manufactures Trust
After the users clicks the link i.e hxxps[://]perfectgoc[.]com/aacggh/OTPWITCALLER[.]html?email=victim@example[.]com , they encounter a parcel themed OTP interface as shown below:
Fig. 2: Fake OTP page
This page is designed to look like a shipment validation step. It is not a real OTP mechanism. Fig 3 shows the verification interface
Fig. 3: Fake OTP page content
Furthermore, the page generates a six-digit number locally in JavaScript. Fig 4 shows client-side OTP generation:
Fig. 4: Client side OTP generation
This is not real verification. It is generated on the client side, without any server interaction. There is no authentication backend, no SMS/email delivery, and no natural identity validation. The victim is being asked to repeat the number as 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. Fig. 6 shows the extraction of victim identity from the hash or query string.
Fig. 6: Extracting identity from hash or query string
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
Here’s the code logic:
Fig. 7: Carrying email forward
Redirect to the second-stage page
When the OTP matches, the user is redirected here:
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 i.e “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 “Confirm & Login” button. Here’s how it looks:
Fig. 8: Credential harvesting page
This is deliberate impersonation designed to make the victim believe that shipment is real, and the account is already recognized and only one final confirmation is needed. The interface is not just imitating a brand but 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 are:
- 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 captured record in a local browser storage.
This may serve as a backup mechanism. Not the primary exfiltration path. Either way, legitimate sites do not store submitted passwords in the local storage for shipment confirmation workflows.
Stage 4: Stolen Data Exits Through a Legitimate Email Service
The most revealing section in the EmailJS configuration. Fig 9 shows the configuration below:
Fig. 9: EmailJS configuration setting
The kit initializes EmailJS and sends the captured data using the configured service (attacker mailbox: slatty077@tutamail.com) and template.
Exfiltration call
“templateParams” stores the victim telemetry.
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:
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
| Subject | DHL EXPRESS WAYBILL CONFIRMATION REQUIRED |
| Compromised/Spoofed Sender Address | info@cupelva[.]com |
| Fake OTP Page | hxxps[://]perfectgoc[.]com/aacggh/OTPWITCALLER[.]html?email=victim@example[.]com |
| Credential Harvesting Page | hxxp[://]biotechgroup[.]net/aaaavbvvb/newengDHL[.]html?email=victim@example[.]com |
| Attacker Mailbox | slatty077@tutamail[.]com |