Recipient Email Hidden After the # in a Phishing Redirect

The recipient's own email address was in the attack, but you would never find it in a server log. It rode along after the "#" in a redirect URL, a spot the browser handles privately and never sends to the web server. That single design choice is what makes this one worth your time.

The target was a shared catering and sales mailbox at a national hotel and hospitality brand. Not a named person, just a functional alias that a lot of vendors and guests write to. The lure was almost nothing: a subject line referencing an "ACH Settlement Report" and a completely empty body. The entire payload was a 312-byte HTML file attached to the message.

An unauthenticated sender that should have been trivial to catch

Start with the envelope, because it fails every test we have. SPF returned fail. DKIM was not present at all. DMARC returned none. The connecting client IP was 23[.]177[.]185[.]225 with no PTR record, and the HELO string was literally [127.0.0.1], a localhost address no real mail server would announce on the public internet. The Message-ID was a bare localhost-style identifier and the Return-Path was empty.

None of that resembles legitimate mail. Authentication alone was enough to quarantine this message, and it did. Stolen or spoofed sender identity remains the workhorse of email attacks. The 2024 Verizon Data Breach Investigations Report (DBIR) found the human element present in 68 percent of breaches, and phishing present in 15 percent, so a lure aimed at a shared inbox that many people watch is a rational bet for an attacker.

But quarantining on auth failure is the easy win. The interesting part is what the attacker built for the messages that do slip past a gateway, because the evasion here was aimed squarely at the scanners, not the mail filters.

A 312-byte launcher that carries no destination in the clear

Open the attachment and there is no phishing page inside it. There is no form, no logo, no text. The file is a launcher. It holds a block of base64-encoded JavaScript that decodes, at runtime, to a single client-side redirect: it sets self.location to a URL and hands control to the browser.

This is a deliberate split. The email body is empty so there is nothing to read and score. The attachment is tiny so it looks inert. The malicious destination never appears as plain text anywhere a static parser would find it, because it is base64-encoded and only assembled when the JavaScript runs. That is textbook obfuscation, and it is why a launcher this small can be more dangerous than a fully built phishing page delivered in the body.

The destination was a throwaway Amazon S3 static-website bucket: hxxp://off-cez-not-lofting-idx-note[.]s3-website-us-east-1[.]amazonaws[.]com. Disposable cloud hosting is cheap, fast to stand up, and borrows the reputation of a trusted provider. Attackers acquiring web services as infrastructure is a well-documented pattern in the MITRE ATT&CK framework, and Amazon S3 static websites are a favorite because they cost almost nothing and disappear before most block lists catch up.

The trick: personalization that never touches the server

Here is the part that changes how you think about URL scanning. The redirect URL did not end at the bucket. It appended a fragment: #?gazab=. Decode the value of gazab and you get the exact mailbox that received the email, something like victim@[company][.]com.

The attacker used it to personalize and confirm the landing page for that specific recipient, a lightweight recon and tracking token. The evasion is in the mechanics of the "#". Everything after the fragment identifier is processed by the browser only. It is never included in the HTTP request line sent to the web server. So the recipient's address does not appear in the S3 access logs, and it does not appear to any scanner that issues a plain request to the base URL to check its reputation. A sandbox crawler fetching off-cez-not-lofting-idx-note... sees an empty or benign page. Only a real browser, executing the JavaScript with the fragment intact, ever assembles the personalized payload.

That is the whole game. Signal-based URL scanning that reasons about the base address is looking at a URL the attacker deliberately left clean.

Indicators of Compromise

The technique maps cleanly across ATT&CK: spearphishing attachment (T1566.001), user execution of a malicious file (T1204.002), and obfuscated files or information (T1027) for the base64 JavaScript and fragment token.

Where signal-based scanning runs out of road

The gateway story here is a good one because auth failure did its job. The lesson is about the second layer. Any attacker willing to use [127.0.0.1] in a HELO will eventually source the same launcher from an authenticated, compromised account, and then the auth check passes and you are left staring at an empty body, a tiny attachment, and a clean-looking base URL.

That is why detection has to reason about behavior in aggregate rather than any single reputation lookup. Themis, our Adaptive AI, models the combination that a signature engine treats as three unrelated facts: an unauthenticated or first-time sender, an empty body paired with an HTML attachment, and a redirect to disposable cloud infrastructure. That cluster is the tell, not the individual base URL. It is the same discipline that underpins effective credential harvesting protection, where the final page is designed specifically to look innocuous to a crawler.

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

According to the Microsoft Digital Defense Report 2024, attackers keep migrating to trusted cloud platforms precisely because that borrowed reputation buys them time, and CISA's phishing guidance stresses that stopping the attack cycle early beats trying to unwind a compromise later. IRONSCALES platform data backs the scale of the problem: 35,000+ security professionals across 17,000+ organizations rely on the platform, and SEGs miss an average of 67.5 phishing emails per 100 mailboxes each month.

Treat the fragment as an intelligence source, not a blind spot

If your controls only inspect what precedes the "#", assume attackers already know it. Log and detonate attachments in a real rendering environment so the JavaScript runs and the true destination resolves. Alert on the pairing of an empty body with a small HTML attachment. And when you triage, remember that a suspiciously clean base URL sitting on disposable hosting is not evidence of innocence. Sometimes the most useful part of the attack is the part the attacker worked hardest to keep out of your logs. One quick control worth confirming today: make sure SPF fail, DKIM absence, and DMARC none actually route to quarantine in your environment, not just to a header stamp.