How 'opened' and 'clicked' stats are measured in AntiPhish simulations

Our methods for measuring and determining user interactions in AntiPhish simulations can be found in this article.

When sending phishing simulations, it can be beneficial to know which emails were opened and/or clicked by specific targets.

For the sake of this article, the example URL we will be using in place of a phishing link is https://antiphish.training/, however for your simulation this will be different.

Generating unique IDs

Upon sending a phishing simulation, a unique ID (called a RId) is dynamically generated and automatically assigned to the target. This RId is unique to the target and is therefore used to track user interactions. The RId cannot be generated prior to the sending of the simulation.

Without an assigned RId, there is no way to measure an intended target's interactions, or 'inform' the phishing server what to do upon user interaction. In most cases, trying to load a simulation URL without a RId will lead to the target seeing a 404 error.

Opens

To track whether an email sent to a specific user has been opened, a 1px transparent image is added to the bottom of each email. When this image is loaded, it fires off an event. The phishing server sees this event, and reads the URL associated with it:

https://antiphish.training/track?rid={{.RId}}

The server reads the URL containing the track parameter and the target's RId, and reports that the email sent to that specific target has been opened.

However, open stats should not be relied upon, as it cannot be guaranteed that the intended target did or didn't perform the action themselves:

• if the target's mail client disables images, an open cannot be recorded.
• if additional security measures prescreen the email on behalf of the user to ensure it is safe to open, an open may be recorded even though it was performed by an automated/third party service.

Clicks

Link URLs are rarely hardcoded into an email template in AntiPhish simulations, instead, we utilise a URL tag that is replaced with a dynamically created URL upon sending the simulation to the target. This dynamic URL combines a predetermined domain with the target's RId. Once the simulation has been sent, the URL tag automatically converts to:

https://antiphish.training/?rid={{.RId}}

As the URL contains the RId associated with a specific target, when this URL is loaded, the phishing server reports that the simulated phishing link has been clicked by the target whom it was sent to.

With correct whitelisting, the only time this link should be loaded is upon being loaded in a browser after being clicked in the simulated phishing email. Some security providers, even with extensive whitelisting, may still prescreen links in emails on behalf of the target, and as such a false positive may occur. Further whitelisting and support enquires with your security provider may be required to determine why whitelisting rules are not being followed.

Click interactions are manually examined by a consultant upon completion of your campaign to determine whether recorded clicks are genuine or false positives, however, other factors may impact campaign stats that are more difficult to determine legitimacy:

• if the intended target forwards the phishing simulation to a third party such as an IT professional within your organisation, and the third party then clicks the link in the simulation, the click would still be associated with the intended target.
• if an automated security service prescreens links from the same IP/IP range as their user proxy/VPN, it can be difficult to determine whether the click was a genuine human interaction by the intended target or whether it was performed by an automated service/third party.

In the event that false positives are present and further investigation reveals it is a result of security services screening the simulations on behalf of the user, this will be noted in your AntiPhish assessment report.