Refer(er) MADNESS!!! “Phish Phinding” with Wire Data

 

I was reading the Cisco mid-year security review and once again, phishing is still staggeringly effective. One of the strategies in looking for possible phishing campaigns is investigating HTTP referrer metrics in log files. This is not a bad way to look for phishing campaigns but I wanted to take the time to cover a log-alternative to investigating phishing attacks using ExtraHop’s Wire Data analytics.

Why wire data?
I recently read a whitepaper by Solarwinds stating that a typical peak events-per-second rate on a web farm is around 1100. Cast this across 6-8 business hours a day and you are looking at paying to store and index between 24 million and 32 million events of which a fraction of that is relevant to searching relevant referrals. While I love logs and the use of them, the intelligence yield of most log solutions can be measured in the “thousandths” of a percent. In this post, I am going to walk though how to look for specific referrers that do not match what you expect to see and provide ONLY the actionable HTTP referrers that could be the result of phishing campaigns.

What do we want to do?
We have a site called demo.example.com that logs users into our fictitious financial site. All users should be sent to a welcome page called demo.extrahop.com:8080 (yes, this is simplistic). We can either hash that HTTP referer or referer(s) and look specifically for referers that do NOT match or we can look for them specifically. You may find that if you have a large number of HTTP referer sites it looks MUCH cleaner to use hashes. For this example we want to look for two things.

  1. Any HTTP referer that DOES NOT match the goodRefer array
  2. Any “double-dotted” namespace that exists in the domArray array. (You may also want to check for “appended” or “double-dotted” namespace on line 7 as well in case you think internal users may get phished and you want to catch it on the EGRESS.)


Okay, we have some unauthorized HTTP referers, we have verified that they are a phishing site now what do we do?
You have several options should you observe unauthorized HTTP referers those that I can think of initially are as follows:

  • If this is an external customer, you can log the credentials on the site and begin the process of alerting them.
  • Build in a redirect policy sending users sourcing from the offending referer to a page that alerts them that they have been phished.
  • Send the data to your poor-overburdened SIEM with some high INTEL-yield actionable logs!!
  • JSON.stringify the results and send them to the FS-ISAC and alert the rest of the community (and punk-bust the offenders that much faster!)
  • HTTP POST the results to your API-driven orchestration and IR solution (ChatOps, Risklense, ServiceNow, etc.)
  • Expose the unauthorized referer data via our API to existing workflows that can check against Threat intelligence.

Within my lab I am writing the data out to our search appliance:

Below we are writing the data to our search appliance with a once-click link directly to the packets for digital evidence and further investigation (Click Image)


Conclusion:
Phishing is still an effective vector for bad actors today and less friction we can put between the practitioner and the data that they need the better. Leveraging wire-data for this task is considerably more-agile than log based solutions and it delivers better data to your existing SIEM investment. Having an open platform like ExtraHop makes integrating incident response, system owners, end users and customers as well as the security community at large more integrated into the solution. We have had stand-alone security for a long time, in some situations that is as good as it gets but where we can, I believe we should leverage the entire community. It is the gaps between us (users, customers, system owners and security) that is exploited as much as any vuln.

Thanks for reading!!

John Smith
Sr. Security Engineer
ExtraHop Networks

 

Leave a Reply