Fishing For Phishing By Matthew Meis, MBA
Special thanks to Matthew Meis, MBA for creating this content on phishing!
Phishing affects every business and every individual. From minor annoyances to top tier fraud, phishing is usually the starting point of an attack. To be better as a security and fraud community, it is time we search out and destroy phishing sites before they make contact with our inboxes. A proactive approach will increase the cost of phishing for criminals and reduce losses for our companies and customers.
As you can see, phishing numbers have a lower directly attributable dollar loss but is often an entry point to other fraud (Ransomware, malware, etc.). Note that these numbers are only based on reported events, actual numbers and losses are much higher.
It’s easy and cheap for an attacker to set up a phishing site targeting your employees or customers.
Deloitte estimated even a low-end cyber attack costing just $34 per month could return $25,000, while the more expensive and sophisticated attacks costing a few thousand dollars could return as much as $1 million per month.
A kill chain is a set of steps criminals use to act on their goal. In this phishing kill chain the criminal’s goal is to steal your banking credentials and then your money.
Our goal as defenders is to catch phishing earlier and disrupt criminals before they reach their goal (compromising victims).
The 8 steps in a DNS lookup:
1.A user types ‘example.com’ into a web browser and the query travels into the Internet and is received by a DNS recursive resolver.
2.The resolver then queries a DNS root nameserver (.).
3.The root server then responds to the resolver with the address of a Top Level Domain (TLD) DNS server (such as .com or .net), which stores the information for its domains. When searching for example.com, our request is pointed toward the .com TLD.
4.The resolver then makes a request to the .com TLD.
5.The TLD server then responds with the IP address of the domain’s nameserver, example.com.
6.Lastly, the recursive resolver sends a query to the domain’s nameserver.
7.The IP address for example.com is then returned to the resolver from the nameserver.
8.The DNS resolver then responds to the web browser with the IP address of the domain requested initially.
Once the 8 steps of the DNS lookup have returned the IP address for example.com, the browser is able to make the request for the web page:
1.The browser makes a HTTP request to the IP address.
2.The server at that IP returns the webpage to be rendered in the browser (step 10).
We use zone files at all steps of the DNS process. There is a distinct file per Top Level Domain (TLD), a TLD could be “.com” or “.net” The TLDs have all registered second level domains in their zone files as well.
A zone file is a plain text file stored in a DNS server that contains an actual representation of the zone and contains all the records for every domain within the zone. Zone files must always start with a Start of Authority (SOA) record, which contains important information including contact information for the zone administrator.
In many cases we can get these files publicly from ICANN. You can see an API and a dashboard link to get them in the slide above.
What can we do with zone files? We can use DNS zone files to look at all domains registered (by TLD) to find newly registered sites. We can then determine if these new sites are a threat or not.
Why should I monitor and what should I be looking for? How do I justify this to management?
Monitoring for phishing proactively has perks for both your company and your customers. Many times the customer is left unprotected by traditional enterprise phishing detection.
Note: you don’t just have to monitor your own domain, monitor all the domains relevant to your business. For example: vendors, customers, and other important 3rd parties could be a fraud vector in the future. You could even monitor industry key terms like: “bank”, “account”, or “loan” to see new phishing related schemes that are less targeted, but still affect your business or customers.
When looking at a site’s technical details we can reach out to the hosting provider, registrar, or certificate authority ask them to take down the site so its not accessible. While they are getting back to us, we can easily report an emails or domains to Microsoft, Google and some other working groups to help reduce the effectiveness of the campaign.
Blocking risky domains you find in zone files and alerting internal employees about an external senders can be great first steps to curtail phishing.
By now I hope you see a lot of low hanging fruit to start detecting phishing that is targeting both your customers and your employees.
We all need to make the decision to be more proactive when it comes to phishing detection. Now that you know it’s possible, what solutions will you implement?
Matt, thanks again for sharing your fraud education content on FraudWit!