The Document Request That Leaked Another Client's Portal

The ask was procedural, which is the point. Subject line: "Please Complete the Document Request." The sender alias read "File Request Team." The body was dressed as a supplier onboarding notice from Aerofiler, a real platform that companies use to collect documents and contracts from vendors, right down to the logo treatment, the footer, and a single button reading "Access Portal." It went to the chairman and chief executive of a small professional-services company, a person with authority to approve things and no reason to audit a form request.

The sending address was os4l@corporacionludafa[.]com.

That mismatch is the whole case in one line, and it is not subtle once you look. But nobody was meant to look, and the more interesting failure sits in a block of code no modern mail client will ever draw.

A vendor portal notice from a domain with no vendor

corporacionludafa[.]com has been registered through GoDaddy for close to a decade, with WHOIS details behind a privacy shield. It is not new, not a typo-squat, and not a lookalike of anything. It simply has no discoverable relationship to Aerofiler, whose branding the email wore, and none to the recipient's company either.

Nothing about the sending domain was engineered to support the story in the body. Some campaigns pay for that alignment, registering something that reads as an onboarding portal. This one skipped it, betting that a recipient reading a routine request would look at the layout and the button, not the sender field.

Two redirectors and one unexplained domain

The "Access Portal" button did not point anywhere directly. It went through an Amazon click tracker at 4sf30m8y[.]r[.]us-west-2[.]awstrack[.]me, the standard open and click instrumentation that comes with sending through Amazon Simple Email Service. Inside that wrapper sat a second redirect, a mail-security link-protection URL at shared[.]outlook[.]inky[.]com/link, carrying a query string with an unexplained third-party domain, chcve[.]com, as one of its parameters plus a long opaque token.

Both wrappers belong to legitimate services, which is why they were used. A hover preview shows a click tracker or a link-protection vendor, both of which resolve cleanly in automated analysis, and the endpoint stays encoded in a token no recipient can read. The footer link presented as www[.]aerofiler[.]com ran through the same Amazon wrapper to the real marketing site, which makes the chain look consistent. Stated plainly: the destination behind the wrapped parameter was never independently resolved here, so treat chcve[.]com as unexplained rather than confirmed attacker infrastructure. That is what makes advanced URL attack protection a context problem rather than a reputation lookup.

See Your Risk: Calculate how many threats your SEG is missing

The button no modern client ever draws

HTML email carries dead weight for old software. Legacy Outlook desktop renders mail with a word-processing engine, not a browser engine, so designers wrap an alternate version of anything fragile in a conditional comment only those clients read, drawing buttons there with vector markup. Every other client skips the block. Nobody proofreads it.

In this message, that Outlook-only fallback button carried a completely different link from the visible one. Not a tracker, not a wrapper: a live, fully qualified onboarding URL on a real Aerofiler customer tenant, with a query parameter prefilling a real email address that belonged to an unrelated organization and had nothing to do with the recipient. Rendered here as hxxps://client-tenant[.]aerofiler[.]com[.]au/onboarding?prefillEmail=person@unrelated-org[.]com[.]au, with the tenant and the address anonymized because both identify real third parties who are not part of this attack.

That single artifact reframes the message. The HTML was not built to imitate an onboarding notice. It was a genuine onboarding notice, lifted whole from a real campaign, with the visible call to action swapped for the redirect chain and the invisible one left as it was. Two things follow, and only two: the template was copied rather than authored, and the copy was partial. The record does not support a claim that the platform itself was breached. What it supports is a production template escaping its intended audience and getting reused.

Authenticated twice, aligned once, trusted anyway

The envelope work was clean. The message left Amazon SES from a27-196[.]smtp-out[.]us-west-2[.]amazonses[.]com at 54[.]240[.]27[.]196, transited a Trend Micro Email Security gateway at inpost[.]tmes[.]trendmicro[.]com on 18[.]208[.]22[.]100, and arrived in Microsoft 365. DKIM passed twice, once for the sending domain and once for the SES signing domain. SPF passed at the Amazon hop. It failed at the Microsoft hop, which is the expected artifact of forwarding through a gateway rather than a sign of spoofing, and the composite authentication verdict came back as a pass with the maximum reason code.

DMARC passed too, under a published policy of none, which deserves less credit than it collects. RFC 7489 frames DMARC as a domain owner declaring a stance on unaligned mail, and a policy of none declares that no action is requested. The evaluation succeeded and no enforcement was ever on the table. None of it spoke to whether a privacy-shielded domain had any business sending onboarding notices under someone else's brand, a question authentication is not built to answer. It is also why gateway augmentation matters here: the mail crossed a security gateway and still landed in the inbox.

What actually flagged it

No blocklist hit, no attachment, no malicious verdict on the visible links. The message was automatically resolved as phishing on the strength of the contradictions: a first-time sender with a high sender risk score, on-brand styling for a platform attributed to a vendor the sending domain has no link to, and a direct approach to a chief executive. One mailbox was affected.

Individually, each of those is arguable. A first-time sender is usually just a new contact. Stacked, they describe an impersonation attempt, and that stacking is the work that belongs to Adaptive AI weighing signals against a tenant's own history rather than a rule waiting for a known-bad string.

Why leaked template residue outlives an indicator

The 2024 Verizon Data Breach Investigations Report puts the median time to click a phishing link at 21 seconds, with stolen credentials involved in 38% of breaches and the human element a factor in 68%. Twenty-one seconds is not an investigation. It is a glance, and this message survives a glance easily.

The residue is worth more than the domains. A hardcoded tenant URL in a fallback branch fingerprints the source template, so other messages built from the same copy carry the same unread block. Sending domains rotate cheaply. An artifact buried in markup nobody reads tends to persist, because fixing it requires knowing it is there.

Indicators of Compromise

MITRE ATT&CK Mapping

CISA's phishing guidance on stopping the attack cycle is the practical baseline for a lure like this, and NIST's definition of phishing is a useful reminder that the technique is defined by the deception, not by the presence of a payload.

See You Next Friday

The most valuable line in this email was one that no recipient would ever see. A hidden fallback button pointed at a real customer's portal and prefilled a stranger's address, which told us more about how the message was made than every visible artifact combined. Copied templates come with copied mistakes. When a document request arrives from a platform you do not have an account with, the answer is not to inspect the link. It is to go to the platform, or to the person who supposedly asked, and confirm the request exists at all.