How can I as a trusted user of a middleman company (such as PhishTank) verify whether a phishing site is valid if the scam listens only on a unique referrer link(randomly created) and is blocking any other access methods?

To throw a threat scenario into scene.

An attacker sent an email to a local bank officer, the email looks very similar to a official email of an employee in their company at a higher tier and the time was planned. Later they detect it was a spear-phishing attack from an old employee. They report the attack on PhishTank (for example), but there they can't verify it because the link doesn't allow direct access (only with a unique referrer as in the email). How can they still verify whether it was a valid report of not?

Now the real question,

On a technical view, how does such an attack work?

  • 1
    If the link only works under heavy restrictions then it is safe to assume it is a phishing link. Commented Sep 19, 2019 at 23:06
  • 1
    @ConorMancone – How do you know? You might not get a 403 error; it might just be completely benign content. Perhaps a phish landing site would just 302-redirect to the site it mimics if the victim isn't coming in through the preferred method.
    – Adam Katz
    Commented Sep 24, 2019 at 19:39

1 Answer 1


Yes, this is a real problem and we have observed it in the wild.

As cloud-based malicious site detection systems get more prevalent, expect a corresponding increase in tightly targeted attacks that are invisible to such detection systems.

This kind of thing can be controlled by an .htaccess file in the payload directory.

HTTP Referer

Limiting access by referrer link (misspelled in the HTTP spec as "referer") won't work for phishing emails because there's never a referrer (unless the attacker uses a redirector service that happens to add one), but it could be done with a rewrite rule:

RewriteCond "%{HTTP_REFERER}" "!www.example.com" [NC]
RewriteRule "^"               "-"                [F,NC]

Restricting access by client IP

Here's another example that limits access by IP:

Require ip 127 

This tells Apache and Apache-compatible servers that the current directory (and all subdirectories) should render a 403: Forbidden to any connecting IP that isn't localhost ( or on the given private LAN IP space. An attacker could, for example, look up a region's IP ranges and explicitly require them.

If the detection system's IP range is known, you can reverse that:

# prevent access from these CIDRs
Require not ip


How can I as middleman verify whether a phishing site is valid if the scam listens only on the referrer link and blocks any other access methods?

You should do everything you can to look like a victim. If you have access to a VPN in the purported target region, use it. If you don't know how the attack is targeted, you'll have to guess.

Forging IP addresses is hard, but there's nothing to stop you from entering whatever you want as the HTTP Referer; it's just a header. If you have to guess, try the same page as you seek to visit. That at least works for most image hosting sites that are trying to prevent direct hot-linking of their content.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .