Recently, I was involved in an incident handling mission to find how some confidential emails were being tracked. Let’s imagine a first scenario: Alice sends a mail to Bob. Bob reads Alice’s email and Alice gets notified. Nothing special, this is a standard feature offered by most commercial messaging solutions. But the second scenario is more interesting: Bob forwards Alice’s email to Chris. Chris reads Bob’s email and Alice gets a second notification. In the second example, Alice’s & Bob’s point of of views are different: Alice would like to know why her (confidential) emails are forwarded to a third party and Bob would like to know why Alice is tracking him. In the scope of my mission, I worked for Bob.
When you start to investigate such incident – because from Bob’s point of view, it was clearly a security incident – you often start to build complex scenarios where bad guys used high-level techniques to compromise the corporate mail server and to steal confidential information. My first step was indeed to review the corporate mail server (based on a classic Microsoft Exchange environment). It started with the classic checks, no malicious processes, no key logger, no suspicious remote access, no SMTP flows to unknown mail relays. Then my focus was on Exchange itself: no filters on Bob’s mailbox, no rogue device connections via ActiveSync, no traffic from unknown IP addresses. The mailbox was not shared with other team members. Once debugging enabled on the mailbox, no suspicious actions were detected. The next step was to focus on the laptop: same proceure, everything looked clean. I did not receive access to the mobile devices (iPhone, iPad). This is a very frustrating situation because you’ve almost nothing “juicy” for write in your report! And suddenly, while searching for information in the mailbox, this was found in one of Bob’s emails:
This tag was not immediately found because the display of the picture depends on the mail client and/or its configuration (the Exchange mailbox was managed from different devices). By default some clients display a broken image, others do not display anything. While moving your mouse over the picture, you see a link to the iTunes page of this app (the “alt” HTTP tag – see below). But if you check the HTML code, you see this:
<a href="http://itunes.apple.com/app/id533886215"><img src="https://itrackmail.herokuapp.com/api/image.php?guid=xxxxxxxx” alt=“This email sent by iTrackMail"></a>
Here we are! When the mail is opened, most email clients will automatically visit the URL above (which returns the image as result). The HTML code being injected in the mail body, if Bob forwards Alice’s email to Chris, the code will remain active and Chris’s mail client will also visit it, and so on… Image the same kind of mail being forwarded to a mailing list? It will be possible to estimate the number of members and their location. Why their location and how?
The application is freely available on the Apple App Store:
It works like this: When you need to track a mail, send it from the application and choose the subject. This subject will be linked to the 8-characters code seen in the URL above for the tracking. Then, the app uses IOS email features to write the mail and send it to the person being tracked. When the mail is read and the URL (https://itrackmail.herokuapp.com/api/image.php?guid=xxxxxxxx) accessed, a push notification is sent to the sender:
Which type of information will be sent with the notification? Based on the HTTP request, there are enough data to identify the different readers:
There are enough information to easily distinguish Bob and Chris when the mail is forwarded. When you upgrade to the pro-version, the HTML code remains the same but the returned image is a classic 1×1 GIF image!
How to detect this application on your network? The tracking being performed on top of SSL, it’s not easy to check for the URL pattern (except if you already have a solution to inspect such traffic). The best best way is to check your DNS resolver logs and search for the presence of A or AAAA queries to itrackmail.herokuapp.com. Then you can correlate with flows sent to this host (which actually resolves to 2 IP addresses in the Amazon cloud: 188.8.131.52 and 54.225.2). The application uses your configured email settings, there is not way to trace a specific SMTP server.
To protect against this threat:
- Sinkhole the FQDN in your DNS (at infrastructure level)
- Do not forward sensitive email but print them in PDF and send the PDF file to your contacts (client side)
- Always prevent your email client from automatically downloading the images present in a mail (client side)
- Write a rule to tag email containing the tracking URL or to move them to a specific folder (client or server side)
To end on a funny note, the iTrackMail serveur is not protected against DDoS! The following code generated 15 notifications on my iPhone in a few seconds, making it unusable:
$ while true do curl -o - https://itrackmail.herokuapp.com/api/image.php?guid=xxxxxx done
Conclusion: When you need to investigate a security incident, do not immediately elaborate complex scenarios. Attackers do not always need high technical or hacking skills to perform malicious actions. Also, email trackers can be considered as legit applications (after all, it was approved by Apple!) but, in this case, the case was different: the tool was used to spy on someone else.