A Salary Portal Phish With No Attacker Domain In It

A national sales director at a fresh produce and food manufacturing company received an email that read as an internal HR notice about a salary increase. The visible body was almost empty: a headline pairing his employer's name with the words "Salary Increase", one line about a salary portal, and a single button reading "Visit Portal." The subject opened with a reply prefix and reused both the company name and the recipient's own full name, borrowing the shape of a forwarded invitation to imply a thread that had never existed.

That button was the entire attack. Everything around it belonged to somebody else. The message was sent from a real mailbox at a small law firm whose domain was registered in 2020 and has no relationship to the produce business. The landing page was served from a British production company's domain, registered in 2011 and still in ordinary commercial use. No attacker-registered domain appears anywhere in the chain, so there was nothing in it for a reputation feed or a domain-age heuristic to fail on.

Four Hops of Borrowed Reputation

Unwrapping the one call to action produced four distinct hosts, and every one of them was infrastructure a security stack has good reason to trust.

The first layer was a Microsoft Outlook SafeLinks rewrite. That is the recipient tenant's own protection service doing its job, and its presence is not a finding. What matters is that the wrapper preserves the pre-rewrite destination alongside it, which is where the rest of the chain was visible.

The second layer was Google Meet's linkredirect endpoint at meet[.]google[.]com, which accepts a destination as a query parameter. The third was Google's own URL redirector at google[.]de, reached with a percent-encoded path through an advertising click-tracking route. Two nested open redirectors on Google-owned hosts, in sequence, doing nothing more exotic than what they were built to do.

The fourth hop was the destination. By that point a proxy log, a URL reputation lookup and a hurried human all see the same thing: Microsoft, then Google, then Google. Chaining redirectors like this is a documented user-execution pattern (T1204.001), and it works because each hop launders the next.

A Path Dressed Up As Autodiscover

The final host was a subdomain of that production company's domain, and both the subdomain label and the first path segment were autodiscover. Autodiscover is Microsoft's own endpoint name for mail client configuration, which is exactly why it was chosen. Read quickly, the destination looks like plumbing. Read carefully, it is a fifteen year old production company's web host serving a Microsoft service name in support of a lure about an HR salary portal.

The record supports abuse of that host, not a confirmed compromise of it, and the distinction matters when you decide who to notify. Either way that company is a bystander, like the law firm whose mailbox sent the mail. Both are targets here, not participants.

The Recipient's Own Address, Base64 And Split

The path did not stop at /autodiscover. It continued with a trailing segment shaped like this:

/autodiscover~[chunk1]~[chunk2]~[chunk3]

Strip the tilde separators, concatenate the three chunks, and you have base64. Decode that, and it is the recipient's full email address.

This is the part worth carrying away. That token is per-victim: it tells the operator precisely which mailbox clicked, and it lets the landing page personalise itself for one named person. It also defeats the obvious control. A check that greps a URL for a plaintext address finds nothing, and a check that looks for a base64 blob finds nothing either, because splitting the encoded string across separator characters breaks the pattern a naive detector matches on. We show the shape rather than the value for the same reason: the value is somebody's mailbox.

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

A Pass That Vouched For Nothing

The authentication story runs in the opposite direction to the one people expect. At first contact the message failed. The connecting address was 2[.]25[.]112[.]123, geolocated to Lithuania, with reverse DNS of srv1917636[.]hstgr[.]cloud, a commodity hosting server. It announced itself with a HELO string claiming the law firm's domain, and SPF failed on the spot. DMARC failed with it.

A later evaluation of the same envelope domain passed, this time from a Microsoft 365 outbound protection address. The headers attribute the two hops to two different tenants, so these are genuinely two separate hops and not one check recorded twice. The message authenticated as if sent by the law firm's own Microsoft 365 infrastructure on a later hop, despite failing SPF at the point of first contact. This is not a gateway rewriting a message after signing it. The failure happened at origin and the pass was acquired in transit.

And the pass vouched for nothing. There was no signature on this message: DKIM was simply absent, so no infrastructure ever attested to the content. The spoofed domain publishes a DMARC policy of none, which asks receivers to take no action on a failure. Under those conditions, dmarc=pass and compauth=pass reason=100 at delivery tell you that one hop aligned with one SPF record, and nothing more. Policy semantics are worth reading in RFC 9989 before treating a pass on a permissive domain as evidence. Our Adaptive AI treats a verdict like that as a starting point, not a conclusion.

Filler Nobody Was Meant To Read

Below the visible lure the body carried a large block of near-invisible text, set to white with an opacity of 0.01 and a maximum height of one pixel. It was a hidden block of unrelated stolen text used as filler, with no connection to the salary pretext. We are not reproducing any of it.

The technique matters even when the content does not. Padding a message with unrelated real correspondence dilutes its statistical fingerprint and drags the ratio of suspicious to ordinary language toward whatever a volume-based classifier considers normal. It is invisible to the reader and costs the operator nothing.

What Actually Caught It

All five extracted links returned a scanner verdict of clean or not applicable, which is the correct answer when every host in a chain is legitimate (T1566.002). The record carries no numeric confidence score for this message, only a label marking the recipient as a high-value target.

What surfaced it was the person it was aimed at. He reported the message himself, and an analyst then confirmed it as phishing. That is the human element working exactly as intended, and it is the same pattern the 2026 Verizon Data Breach Investigations Report puts numbers to when it attributes 16% of breaches to phishing as the initial access vector and 39% to credentials somewhere in the kill chain.

Two identical copies reached the same mailbox five minutes and twenty two seconds apart. Only the second shows a quarantine action, a reminder that a report closes one message while a campaign is rarely one message. Guidance on running that reporting loop sits in CISA's phishing guidance, and the baseline definition of the technique is in the NIST glossary. The control that mattered most here reads intent rather than infrastructure, which is what credential harvesting protection must do when all the infrastructure is borrowed.

Indicators of Compromise

MITRE ATT&CK Mapping