• Suggested additional reading:  Analysing Phish Reponses - Determining if phishing emails have been forwarded / viewed on another device(s)

Phishing Response & Reported IP Addresses

Determining if a reported IP is pointing to an actual user or your mail defence(s)

Overview – what to do when running campaigns and discovering “false positives”
 

Problem we’re solving: After successfully configuring your mail rules to ensure that your Mock Phishing emails arrive in your users’ inboxes, your results report that your users have either:

• Clicked on a link / image contained within the mock phishing email and / or
• Filled in form details and / or
• Opened an attachment etc.

Yet you are confident that they have not performed any of the above actions. 

Why is this happening?

All emails (including our Mock Phishing emails) that are passing through your mail systems will be checked by your mail defences.

As part of this process, your mail defences may examine:

• Links contained within the Phishing email and 
• Any attachments that may be included

These examinations can often result in our system recording that the user(s) in question have either clicked on the link or opened the attachment where in fact they have not – these actions are being marked as such due to your email defences scanning the emails’ contents.

This then is resulting in a false positive where our systems record that the user(s) – and not the mail defences – performed the risky action.

How to solve this issue

Your email defences will also have an IP address which is recorded per every action, and this will show in your results. Where we suspect a false positive, we then query the recorded IPs and determine the IP Ranges for these actions to see if they belong to a known IP Range for recognised mail defences.

Mail defences can include (for example) Microsoft, Barracuda, Mimecast, Symantec.Cloud etc. 

Where we find that they do belong to existing mail defences, we can then:

• Blacklist those ranges within your SafeTitan Portal
• Re-ingest (or re-assess) the campaign results to take these newly added ranges into account and correct this, and finally:
• Re-calculate your results to reset results for the affected users.
  

The following steps will show how this is done.

Reviewing a Campaign

In the following example we are looking at a campaign titled “Docusign-Test” and we see that this campaign had reported the following users as having opened the attachment as below:

So, let’s investigate the reporting IP for those results. You do this from your portal by clicking on:

Dashboard -> Phishing Manager -> Select the relevant campaign – in this case "Docusign-Test" -> View -> Results Analysis.

The IP addresses recorded were (in this example):

• 40.94.104.126 and 
• 40.94.88.126 

On the following pages we will:

1. Investigate both of these IP Addresses to assess if they belong to a mail defence.
2. Discover the wider IP Range they belong to.
3. Confirm / double check that the IP belongs to the reported IP Range.
4. Once confirmed as a mail defence, we will blacklist the IP Range on our SafeTitan portal.
5. We will then Re-ingest (or re-assess) the IP Ranges reporting these actions to correct entries marked as false positives.
6. We will finally Re-Calculate our user results.

IPs Reported: 40.94.104.126 (and 40.94.88.126)

Step 1 – IP Address lookup - Using the website IP Location Finder, we enter the IP:

We then see the following results, which shows what organisation it belongs to (in this case – Microsoft):

We discover that it is a Microsoft IP, located in Austria.

So it is an IP Range we can blacklist from our Phishing settings (more on this below). 

Step 2 – Confirm IP Results and get IP Range

Using a second website ipinfo.io, we confirm the results above and get the IP range: 

• Here we see that the IP Range for 40.94.104.126 is 40.80.0.0/12
  
  
• In the same way we see that the IP range for the second IP (40.94.88.126) is also 40.80.0.0/12
  
  
  

Step 3 – Confirm IP address belongs to reported IP Range

Using Technoblog’s IP Address in CIDR Range Check Tool, we confirm that (both) IPs do in fact belong to their reported IP Range(s).

In the image below we have checked the first IP / Range, the same method is used for the second.
 

Step 4 – Blacklisting a confirmed IP Range 

Once we confirm an IP Range as a Microsoft (or other known scanning IP range), we blacklist it in our PhishHuk settings.

• Note: The image below is taken from a test portal.
  
  
• To see this screen, click on Dashboard -> Configuration -> Phishing Settings and add the IP Range(s) in the field marked IP Blacklist as below.
  
  If there is more than one IP range, use a semi-colon after each entry.
  
  
• Additionally, if you use Microsoft Defences generally, you can add Microsoft Corporation to your ISP Blacklist. This will generally mean that MS IPs will not be recorded as coming from your users, but  rather from your defences. These will be discarded.
  
  
• However, as Microsoft and other vendors expand their infrastructure regularly, we may not always be 100% up to date with their IP Ranges, so you may need to add IP Ranges periodically.
  
  
• Please leave the Use global defence list boxed checked at all times, and finally, Click Save:
  
  
  

Step 5 – We then Re-ingest (or re-assess) the results
 
Here we re-analyse the IP addresses reported to also look at our newly added mail defence IP Ranges etc.

To do this Go to Dashboard -> Phishing Manager -> and click the View button for the relevant campaign (again in this case - Docusign-Test)

Then Click Result Analysis -> and then the Recalculate Action Ingestion button:
Note: Again this image is from a test portal
 

Note: Please allow 2 - 3 minutes before proceeding to the next and final step

 
Step 6 – Finally, we Recalculate the results

 The final step is to have the system re-run the results based on the updated IP ranges. With this step the record set is updated, and false positives are removed.

To do this Go to Dashboard -> Phishing Manager -> and click the View button for the relevant campaign (again in this case - Docusign-Test)

Then Click Campaign Results -> Recalculate Analytics

So now we see that John Doe and Jane Doe have been removed from the users reported as having clicked the attachment.

Important Notes

It is important to run a number of test campaigns before rolling out to your wider user base in order to confirm that there are no false positives being reported as we’ve seen above.

It is absolutely normal to discover that there may be a number of IP ranges that need to be added to our Phishing configurations during testing, and these test campaigns will help highlight IP Ranges of your defences that we need to add.

Ideally your network engineers / IT team may be able to provide you with a list of the IP Ranges (of your defences) that you will need to add.  

The steps described here, combined with our built in Global Defense List should get you up and running successfully, once implemented correctly.

However, we would suggest that before running large campaigns in the future – and particularly where a month or two has passed since your last tests - that you again re-run some smaller Phishing Tests to ensure that your Phishing IP Blacklist remains up to date.

Phish response IPs – determining if a phish has been viewed on another device or forwarded

You may see that in some cases different IP addresses will be recorded for the same user. This can happen:

• Where a user views their email on different devices or networks – e.g.
  1. On their primary work device (desktop / laptop) and
  2. On a secondary mobile device that may be using a different / mobile network (and therefore be assigned a different IP address)
• Where a user views the phish / email and then forwards that email to a different user

So how do we determine which is the more likely of the two scenarios above

The answer is to look at the reporting IP addresses in a similar way to how we looked at them above.

Note: This task becomes more complex where users are connecting to VPNs in order to access the Internet / your systems, so please let us know if this is the case.

Example 1 – User has likely viewed the phishing email on their own local device and then also on a mobile device

So looking at the two IP addresses above for the user [email protected], we can see that the first one is Eircom (an Irish ISP)  - and the second is Three (an Irish cell phone / mobile internet service provider).

We also note that the reported times are very close together (within a minute / minutes of each other).

Eircom – Irish Telco / ISP

Three – Irish cell phone service provider / mobile ISP

So while this is not conclusive, it’s reasonable to assume (given the closeness in time of the reported clicks and that they’re both Irish ISPs) that this is likely the same user, firstly on their primary device and secondly on their mobile phone or other device.

There will be exceptions to this general rule, so further analysis may be required on a case by case basis.

Example 2 – User has viewed the phishing email on their local device but then forwarded to another user

In the above example for the user [email protected], we see again two IP addresses.

Where we look up the Eircom IP we again see that this is an Irish based ISP as shown below. We also know that this user works in Donegal (Ireland), and so this is likely their home ISP / broadband provider. We look it up to confirm using Iplocation.net as below:

We then lookup the second IP address reported:  68.235.38.164. This one seems unusual as we do not recognise the ISP (Tzulo Inc).

We find that this IP is based in the USA (Illinois):

This tells us that the user has most likely forwarded the email onto someone in the US, as the time recorded for the US click was only 30 minutes after the Irish click.

If you have any questions on any of the above, the support team at SafeTitan will be on hand to help you at all times if required.

We are here to help you. Please do not hesitate in reaching out to us should you need any further assistance.

Suggested additional reading:  Analysing Phish Reponses - Determining if phishing emails have been forwarded / viewed on another device(s)