2

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?

7

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.

  • This rings true to me, I didn't consider that the initial link may have been "corrected" at some point and rewritten. Thanks for your help! – Floegipoky Jul 10 at 21:05
  • @schroeder The snippet contains #%23email%23%23 (with one "real" # and three encoded ones) so would render to ##email##. – TripeHound Jul 12 at 9:11
  • @TripeHound darn it, I missed that! I still think that with the rendering issue, they pulled a "Dwigt". – schroeder Jul 12 at 9:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.