Mystery link containing fragment identifier in malicious email

Question

The following link was received in a suspected phishing attack email. Unfortunately, the recipient clicked on the link in their outlook client:

<tr>
    <td class="m_-[string-of-19-numbers]m_-[string-of-19-numbers]gmail-x_gmail-summaryIfMobile" style="text-decoration:none;padding:18.1px 13px;background-color:rgb(212,238,246);font-family:Trebuchet MS;font-size:11px;font-weight:normal;font-style:normal;text-align:left;color:rgb(80,80,80)">
    This summary of your queued emails for the last 7 days. Please use the
    retrieve queued emails to release emails your email account <a 
    rel="noopener noreferrer" href="http://#%23email%23%23" target="_blank">info@email.address</a> inbox.</td>
</tr>

The user reported that it opened a new window in their web browser (firefox), which is expected based on the target. I'm trying to determine the possible scope of the breach. Ordinarily I would assume http://#%23email%23%23 is a broken link, since there's no actual resource identifier before the fragment identifier. However, given the phishing and the client-side nature of fragment identifier interpretation, I'm left wondering:

What was the attacker trying to do with this link? How can fragment identifiers be abused? Are there other areas of this email that I should look to for clues?

Answer 1

I have an idea. It boils down to "they goofed". Let me lay out my reasoning first, though:

1. %23 is percent-encoding. It's how you encode special characters in a URL. The format is a percent sign, followed by the hex value of the byte being encoded. You'll also see it frequently with parens (%28/%29), spaces (%20), and equals signs (%3D).
2. So %23 = whatever codepoint 0x23 is, aka #.
3. So their URL is equivalent to ##email##, once URL decoded.
4. ##email## isn't very likely to appear in random text, so it'd make a good template string.
5. A lot of things -- email clients, browsers, Markdown parsers, whatever -- will try to automatically correct broken URLs. For example, adding https:// in front, and url-encoding characters to avoid ambiguity.

So based on that reasoning, here's what I think happened:

1. They had some mass-market phishing email template, ready to be blasted out to millions of potential suckers.
2. As part of that, they had a placeholder for the phishing URL, to be replaced when the email is sent out.
3. Either:
   • They use something like Markdown, which is rendered to HTML, and then do their template replacement. The rendering engine they use autocorrects URLs, so ##email## got changed, and therefore didn't get replaced by a naive search-and-replace.
   • They just plumb forgot to do the replacement, and something between them sending and you receiving (maybe even your email server) replaced the extra #s with %23. If you're looking at the source in the Inspect pane of a browser, it's likely that your browser is 'correcting' the URL, to show where it's been interpreted as pointing to.

In short: They're probably not trying some complex exploit. They did their spam wrong. Barring something extremely weird in your browser, you should be fine.

Still definitely get that employee retrained, though. This time, they got lucky. Next time, they might not.