Table of Contents
A billing notice arrived carrying the display name Verizon. It hotlinked real Verizon brand images, embedded a genuine verizon.com tracking pixel, and quoted a plausible bill date and dollar amount. It also passed SPF, DKIM, and DMARC without a single failure. On paper, it was a clean, authenticated message from a Fortune 20 carrier.
None of that was true. The message came from a Peru-hosted virtual server, the authentication belonged to a domain that has nothing to do with Verizon, and every link the reader could click resolved to a free Blogspot page. The receiving security gateway had already made up its mind before the message hit the inbox, tagging it as phishing with a 9.25 severity score. A human analyst confirmed the disposition. This is worth studying precisely because the technical checks that most people trust all came back green.
Authentication that proves the wrong thing
The email was sent from proyectosti@alknetworks[.]com, a domain the attacker controls. That is the entire trick. SPF, DKIM, and DMARC all passed, action=none, because they were validating alknetworks[.]com, the sender's own infrastructure, not the brand printed in the display field. Authentication checks answer one narrow question: did this message really come from the domain it claims to send from. They never answer the question a reader actually cares about, which is whether the sender is who they say they are.
The originating client authenticated at server.perubyte[.]com on 8.221.101[.]111, an address the gateway geolocated to Poland, then relayed through an OVH virtual server at 57.128.200[.]145 (vps-ca3df597.vps.ovh[.]net) before delivery. A carrier of Verizon's size does not send transactional billing mail from a Peru VPS through a French hosting relay. But because the attacker published correct DNS records for the domain they were sending from, the alignment math worked out and DMARC returned a pass.
IRONSCALES flagged the message as an Exact Display Name Impersonation. The platform's known-good Verizon sender is noreply@verizon-promos[.]com, and this message matched neither that address nor that domain. That is the tell a static gateway keeps missing: authentication aligned perfectly to a domain the recipient organization had never seen from Verizon before.
Real brand assets, a fake bill, a Blogspot page
The body was built to look legitimate. It pulled Verizon's own hosted images directly from the verizon.com content delivery network and included a genuine verizon.com tracking-pixel URL, so the visual layer was, quite literally, Verizon's. The fabricated bill date and amount supplied the urgency, the standard nudge to log in and settle a balance before a due date.
Then the links betrayed everything. Every actionable element, the view your bill button and the login and forgot-password prompts, pointed to pootieppbum.blogspot[.]com, a free Google-hosted Blogspot page standing in as the credential harvesting landing page. No verizon.com login. No carrier property of any kind. A brand that operates its own account portal was routing password entry through a free blogging service, which is the kind of contradiction that should end the conversation immediately.
See Your Risk: Calculate how many threats your SEG is missing
Mapping to MITRE ATT&CK
The tradecraft maps cleanly onto the MITRE ATT&CK framework:
- T1585.002 Establish Accounts: Email Accounts covers the attacker standing up their own domain and mail infrastructure specifically so it would authenticate cleanly.
- T1656 Impersonation covers the Verizon display name and the hotlinked brand assets, borrowing a trusted identity the sender has no connection to.
- T1566.002 Spearphishing Link covers the payload: no attachment, no malware, just links steering the reader to a credential-capture page.
Indicators of Compromise
| Type | Indicator | Context |
|---|---|---|
| Sender address | proyectosti@alknetworks[.]com | From address behind the spoofed Verizon display name |
| Sending domain | alknetworks[.]com | Attacker-owned domain, fully SPF/DKIM/DMARC authenticated, unrelated to Verizon |
| Originating host | server.perubyte[.]com (8.221.101[.]111) | Authenticated client, Peru VPS, geolocated by the gateway to Poland |
| Relay host | vps-ca3df597.vps.ovh[.]net (57.128.200[.]145) | OVH virtual server used as the delivery relay |
| Landing page | hxxps://pootieppbum.blogspot[.]com/ | Free Blogspot page serving the fake bill-view and login prompts |
Detection has to read intent, not headers
Reputation and authentication checks were never going to stop this one. The sending domain had a clean record because it was purpose-built, the links pointed at Google-owned Blogspot, and the images came from Verizon's real CDN. Every individual signal a header-based filter inspects looked defensible in isolation. Detection has to weigh the relationship between them: a first-time sending domain claiming a major brand, transactional mail originating from consumer-grade VPS hosting, and login prompts that resolve anywhere except the brand's own property.
That relational read is what Themis, the Adaptive AI analyst on the IRONSCALES platform, is built to perform, comparing the claimed brand against the actual sending domain and link destinations the way a trained analyst would, and catching the mismatch even when every server-level check aligns. Because DMARC can only speak to the domain in the header, it will happily pass a message like this one. The 2024 Verizon Data Breach Investigations Report puts phishing in 15 percent of breaches and the human element in 68 percent, and the Microsoft Digital Defense Report 2024 documents the same drift toward abusing trusted brands and cheap hosting rather than breaking anything. The FBI's 2023 Internet Crime Report ranks brand and identity impersonation among the costliest fraud categories, which is exactly the lever this campaign pulled. Across the 35,000+ security professionals and 17,000+ organizations that inform our detection, this pattern of clean authentication paired with a mismatched destination is one of the most reliable impersonation tells there is.
Treat the display name as a label anyone can print. Verify the destination. Real carriers do not collect your password on a blog.
CISA's guidance on recognizing and stopping phishing early is a useful reference for building that reflex across a team: https://www.cisa.gov/resources-tools/resources/phishing-guidance-stopping-attack-cycle-phase-one
Related attacks
| Attack | What happened |
|---|---|
| The DocuSign Lure That Used Google as a Trust Shield (And Encoded Your Email in the Link) | A DocuSign phishing email hid its harvest domain behind a google.com redirect and encoded the recipient's exact email address into the link as base64. |
| The Button Text Was the Weapon: Unicode RTL Obfuscation Inside a DocuSign Lure | Attackers embedded Unicode right-to-left marks directly inside a CTA button label to scatter the string for NLP scanners. |
| Instagram Homoglyph Phish Abuses Google Redirect API | One lowercase letter turned a routine Instagram notice into a credential trap. |
| Amazon SES Abuse Delivers Fake DocuPortal+ Notification to a Credential-Harvest Page With a Fake reCAPTCHA | Attackers routed a fake DocuPortal+ document-share notification through Amazon SES, giving it legitimate SPF and DKIM signatures. |
| MSC Brand Impersonation Abuses a Legitimate Open Redirector and Base64-Encodes the Victim's Address for Targeted Tracking | Attackers cloned Mediterranean Shipping Company branding, then funneled victims through a redirect endpoint on a legitimate third-party retail site to... |
Explore More Articles
Say goodbye to Phishing, BEC, and QR code attacks. Our Adaptive AI automatically learns and evolves to keep your employees safe from email attacks.