Anatomy of a Link Click

Observe how automated link inspection reaches a destination before the browser request.

Dr. Ahmet Furkan Aydogan · aydogana@uncw.edu · Department of Computer Science, UNCW

Part I — Background: What you need to understand first

1. Overview and learning objectives

Every day, email security products defend users by inspecting links. To decide whether a link is dangerous, the security layer often opens the link itself. That single design choice — a machine visiting your link before you do — is the subject of this lab.

By the end of this lab you will be able to:

• explain what URL rewriting and “Safe Links” pre-fetch are, in plain language;
• produce first-hand evidence that a scanner reaches a link before your browser;
• distinguish an automated scanner request from a human click using observable signals;
• describe at least three security weaknesses that pre-fetch behaviour enables; and
• discuss the privacy and reliability trade-offs of scanning every emailed link.

2. Key terms

URL rewriting. Before a message reaches your inbox, the email security layer may replace each original link with a link that points to its own servers first.

Safe Links. Microsoft’s URL-rewriting and link-checking feature in Microsoft Defender for Office 365. It evaluates the destination at click time before allowing the user through.

Pre-fetch. When the security service fetches the destination URL with its own network client — not your browser — to inspect it. If this happens before you click, a request “nobody made” reaches the destination first.

Canary URL. A unique, unguessable, single-purpose URL created so that any request to it is meaningful. Canary URLs are the measurement instrument of this lab.

3. The original experiment and its evidence

Three canary URLs were mailed to the researcher’s own Microsoft 365 inbox. Only one was ever clicked. Only the clicked canary received traffic; the never-clicked controls stayed silent — so the scan happens at click time, not on delivery. And the very first request to the clicked canary came not from the browser, but from a Microsoft IP, milliseconds earlier.

Table 1. The pre-fetch signature: a Microsoft HEAD request arrives before the user’s own GET.

4. Telling a scanner apart from a human

The classroom server labels each hit with a simple, transparent heuristic: any one matching signal marks a request as SCANNER; otherwise it is USER.

Table 2. The classification heuristic used by the live dashboard.

5. The classroom lab environment

You will not build any infrastructure. The instructor runs a small logging server that gives each participant their own private view. Open it with the Launch Lab button at the bottom of this page and enter the class access code announced in class — no personal account, Student ID, or payment is required. Your dashboard shows your own canary link and refreshes on its own every few seconds.

Part II — The assignment

6. Procedure

1. Open your dashboard. Use the Launch Lab button, enter the class access code, and confirm you land on your own dashboard. Keep this tab open — it refreshes on its own.
2. Read your canary link. Your dashboard shows your personal canary link at the top.
3. Email the link to yourself. From your UNCW mailbox, send a new email to your own UNCW address with your canary link in the body. Do not send it to anyone else.
4. Wait, then click. Open the email and click the link once.
5. Watch your dashboard. Within a few seconds, rows appear. Look for a SCANNER row that arrives before your own USER row.
6. Take a screenshot clearly showing at least one SCANNER row before your USER row. This is required evidence.

7. Analysis questions

1. The gap. What was the time difference between the first SCANNER hit and your own USER hit? What does a scanner request arriving before your browser request tell you about how the link was inspected?
2. The signals. For the SCANNER row you captured, which signal(s) caused the label? Give one way this heuristic could be wrong.
3. Single-use links. Explain how pre-fetch can break a “reset your password” link. List two other links that are supposed to work only once.
4. What the link reveals. Look at the rewritten Safe Links URL. What information about you or your organisation is embedded in it, and why is that a privacy concern?
5. Trade-off. Give one clear benefit and one clear cost of scanning every emailed link. On balance, is it a good default?

8. Deliverable and grading

Submit a single PDF named Lastname_Firstname_Lab1.pdf containing a title block, your observation log, the required dashboard screenshot, and your written answers to Q1–Q5.

Individual assignment. Send canary links only to your own UNCW address. The lab server hosts only inert, planted demonstration data.