Where the Link Really Goes: Peeling a Tracked Phishing URL
The challenge
A nurse at Meridian Health forwarded a payslip notice to the service desk because the wording felt off. The link in it points at a click tracker the marketing team genuinely uses, so the mail gateway let it through and the URL reputation check came back clean. That is the whole trick: the tracker is real, and the destination is parked inside one of its query parameters. Whoever built the mail did not want that parameter read at a glance, so they wrapped it in three layers before pasting it in. You have the value of the u parameter and a workbench. Peel it, read the address the click would have landed on, and submit the host.
What you'll learn
- Identify percent-encoding from the characters at the head of a value
- Recognise reversed base64 by where the padding sits
- Order decoding operations from the outermost layer inward
- Use a decoder failure as evidence about the layer beneath it
- Explain why a reputable redirector launders a malicious destination
Skills tested
Prerequisites
- What base64 and percent-encoding look like
- The parts of a URL
How it works
Layered obfuscation is only intimidating until you stop reading the middle of the string. The information is at the edges. This value opens with %3D and carries a %2F further along, and percent signs followed by two hex digits mean exactly one thing, so the outer wrapper is percent-encoding and URL Decode is the first move.
What comes out is =AXasNXeh.... The character set is the base64 alphabet and the length is right, so the obvious next click is From Base64, and it fails. That failure is the most useful event in the exercise. Base64 padding is defined to sit at the end of the string, so an equals sign at the front is not a broken value, it is a correctly formed value that has been turned around.
Reverse produces aHR0cHM6Ly9... ending in a single =. The prefix aHR0cHM6Ly9 is worth memorising: it is the base64 encoding of https://, and it appears at the head of every base64-wrapped URL you will ever triage.
The decoded destination is https://meridian-hr-verify.example/sso/renew?u=t.okonkwo&ref=payslip. The lookalike host is the payload; the pre-filled u parameter is the polish, letting the fake sign-in page greet the recipient by name before she has typed anything.
The part worth carrying away is the delivery. The gateway inspected a genuine vendor domain with a genuine reputation, and no reputation service scores the query string hanging off it. Any endpoint that redirects to a user-supplied destination is a laundering service, which is why an open redirect is worth reporting on its own.
Common mistakes
- Trying From Base64 first and concluding the value is corrupt. It is intact; the percent-encoding is still on it and it is back to front.
- Reversing before URL-decoding. That splits
%3Dinto characters that no longer mean anything. - Answering with the tracker's domain. The tracker is a real vendor and is not the destination.
- Submitting the whole URL when the question asks for the host. Read the answer label before typing.
- Reaching for ROT or Atbash. Nothing here is a letter-substitution cipher; the palette includes decoys.
How to defend against it
The mail gateway was not wrong about the tracker. The control has to reach past it.
- Rewrite and detonate links at click time rather than scoring them at delivery, so the final hop is what gets judged.
- Follow redirect chains in the gateway and evaluate the last URL, not the first.
- Ask the tracking vendor to restrict destinations to registered domains. A redirector that accepts any destination is an open redirect with a contract attached.
- Treat newly registered lookalike domains as a detection:
meridian-hr-verify.exampleis a string-distance match on a brand you own and should alert on registration. - Phishing-resistant sign-in beats decoding. A passkey will not authenticate to a host that is not the real one, whatever the user clicks.