Blastin and Castin - Part 1

Over a 4 part series of posts we hope to outline what worked for us in reducing our infections as a result of phishing from 40% to less than 5% without any end user interaction. We know this sounds ridiculous but hang in there and you will see how a bit of creativity and grit can get similar results for you.

Problem Statement:

We can break the phishing issue into a few main issues that we had to deal with:

  •     Volume Increase - The sheer volume of phishing campaigns is growing
  •     Aggressiveness Increase - the campaigns and attacks were becoming much more sophisticated
  •     Lack of/Ineffective User Education - No matter how much we told users not to click they still were


It's easy to take the road that it is a user problem and our job is done but we still have to deal with all of the effects of phishing without any of the control. We become victim to our own laissez faire approach.

We decided to at least attempt to make a technology driven approach without buying any solutions.

What we had:

  • Email Proxy - Cisco ESA
  • Email System - On-Prem Microsoft Exchange
  • Logging - Splunk
  • Grit

Making ESA Logs Useful:

If you have ever interacted with these logs you have probably turned around already :) The crux of these logs is that there is a separate data field on each event and anywhere from 1-18 different events for each message. That means millions of disjointed events a day you have to search and try to piece together.

This is where the Splunk ninjas are saying just use the transactions command in Splunk. We did some testing with it and seemed to get better and more consistent results with the stats command by internal_message_id (MID).


Below is the core search for compressing the multiple events of an ESA log into a summary index where each event represents a complete email:

|stats values(icid) as icid, earliest(_time) AS time_start,latest(_time) as time_stop, values(recipient) as recipient,values(sender) as sender,values(message_subject) as message_subject,values(vendor_action) as vendor_action, values(reason) as reason,values(message_size) as message_size,values(attachment_filename) as attachment,values(attachment_type) as attachment_type by internal_message_id 
|fillnull VALUE="" attachment 
|join type=left icid
[search index=cisco_esa email_dns_name!=""
[search index=cisco_esa 
|fields icid|dedup icid]
|eval email_dns_name=if(email_dns_name="unknown",dest_ip,email_dns_name)|fields icid, email_dns_name, email_dns_verified]


Figure 1. summary_esa event with all of the compacted fields.

Figure 1. summary_esa event with all of the compacted fields.

What is also happening is that it is grabbing the DNS information for the email because of a relationship between ICID and MID. This will come in handy as we analyze phishing emails. See Figure 1. for an example of this event.


To use this, setup a summary index, which does not count against licensing so learn to leverage them. Then setup a report with the search above and schedule it. Because email is always coming in and we did not want fractured results we run the following:

  • Earliest: -10m
  • Latest: -5m
  • Schedule: Every 5 minutes
  • Enable Summary Indexing


Now we have a faster compressed and easier to search index for email. In our environment, the summary index ended up 10% of the size of the ESA index for the same timeframe.


Email Searcher:

Once we have a solid data source we wanted to search it for phishing emails we did know about to find all of the affected users. We built a Splunk dashboard to allow you to search by almost any field:

The sourcecode for this can be found at:


This is a solid base to begin hunting for emails and patterning malicious behavior and will be leveraged significantly as you travel down the path of hunting with emails.

Up Next in Part 2:

  • The variables for measuring valid, spam and malicious emails
  • Dashboard of phishing searches focused on different tactics
  • Phishing Signatures, can help track changes in tactics, volume and scope