When Trusted Links Turn Malicious: Why Phishing Defence Needs More Than Email Filtering

A phishing message does not have to look obviously suspicious at the moment it reaches an inbox.

That does not make email filtering unimportant. It means email filtering cannot be the entire defence.

Recent research from the KnowBe4 Threat Lab provides a useful example. KnowBe4 reported a phishing campaign that used legitimate Google services in parts of its redirect paths, personalised the eventual phishing page and included variants involving legitimate remote-management software.

The campaign-specific details belong to KnowBe4's research. The wider business lesson is this:

Security controls need to assess the whole attack journey.

The email is only the start of the journey

Traditional phishing controls quite reasonably inspect the original message:

• who sent it;
• which domain sent it;
• whether the attachment is suspicious;
• where the URL appears to lead; and
• whether the message resembles known malicious activity.

Those are valuable signals. But a modern phishing attempt may continue through several stages:

email → trusted infrastructure → redirect chain → attacker-controlled page → credential capture → possible endpoint activity

Each stage creates another opportunity to detect or interrupt the attack. It also creates another opportunity for a control focused only on the original email to miss what happens next.

The important question is not only, “Did the message pass the filter?” It is, “What could happen if the user follows it?”

Why reputation alone is not enough

Domain and URL reputation are useful because known malicious infrastructure should be blocked. But a legitimate service can be used as one part of a malicious redirect chain.

A trusted domain must not automatically mean a trusted outcome.

This does not mean Google was breached or that Google's infrastructure is inherently unsafe. It means attackers can sometimes use legitimate services in ways the service owner did not intend. The trust placed in those services by users and automated security systems can then become part of the deception.

For an SME, that points to a proportionate control question: can the security environment inspect where a link ultimately goes, rather than relying only on the first domain visible in the message?

The identity layer

If a user reaches a convincing page and enters a password, the next layer is identity protection.

MFA remains important, but it does not make phishing impossible. A stolen session, a socially engineered approval or a user entering information into a fraudulent workflow can still create risk depending on the attack and the controls in place.

Identity protection should therefore be considered as a group of controls:

• MFA for important systems and accounts;
• phishing-resistant authentication where it is appropriate and practical;
• Conditional Access policies that reflect user, device and location risk;
• suspicious sign-in detection and review; and
• least privilege and monitoring for sensitive roles and unusual access.

Identity controls are another opportunity to prevent a stolen credential becoming a successful compromise.

The endpoint layer matters after the click

Endpoint protection matters after somebody clicks. Useful capabilities can include:

• endpoint detection and protection;
• application control appropriate to the business;
• monitoring unexpected software execution;
• controls around unauthorised remote-access tools; and
• alerting on behaviour that does not fit the normal pattern.

Remote access needs governance

KnowBe4 reported variants involving ScreenConnect. ScreenConnect is legitimate remote-management software. The lesson is not that ScreenConnect is malicious.

The lesson is that businesses should know which remote-access tools are authorised, who is allowed to install or use them and what happens when an unexpected tool appears.

Could we tell the difference between the remote-access software our IT provider legitimately uses and one unexpectedly installed by an attacker?

The human layer still matters

Convincing phishing pages do not make staff awareness pointless. They make simplistic awareness training inadequate.

Training based only on bad spelling, strange-looking domains or fake logos will miss some well-prepared attacks. People also need to understand:

• unexpected authentication requests;
• unusual sign-in or document-sharing workflows;
• when to verify a request through an independent channel;
• why unexpected software installation is a security event; and
• how to report something suspicious without worrying about blame.

What a layered SME defence looks like

A practical model does not begin with a shopping list. It begins by assigning each layer a job:

• Email: filter malicious and suspicious messages.
• Web and URLs: inspect destinations and redirect behaviour, not only the initial domain reputation.
• Identity: enforce MFA, apply Conditional Access, monitor sign-ins and limit privileges.
• Endpoint: detect suspicious execution and control unwanted software.
• Remote access: know and govern authorised remote-management tools.
• People: train staff around modern attack behaviour and easy reporting.
• Monitoring: make sure important security signals are reviewed and acted upon.
• Recovery: maintain appropriate backup and incident-response capability if prevention fails.

This is defence in depth. It is not buying more products for the sake of it. It is making sure that evasion of one control does not automatically result in compromise.

Seven questions worth asking your IT provider

1. Is MFA actually enforced for our important systems?
2. Can our security inspect redirect chains rather than trusting the first domain?
3. Are suspicious Microsoft 365 sign-ins monitored?
4. Which remote-access tools are authorised on our computers?
5. Would we know if an unexpected remote-access tool appeared?
6. Can staff report suspicious emails easily?
7. What happens after someone clicks something malicious?

The last question is especially important. It moves the conversation from, “Do we have spam filtering?” to:

“What happens if the spam filter misses something?”

That is the point at which email security becomes an operational security discussion. It also fits the risk-led approach in Altitude IT's cybersecurity roadmap guidance.

Security needs to be checked, not just installed

Phishing defence is not a one-time installation. Controls need to be configured, monitored, checked, maintained and reviewed as threats and businesses change.

That is the practical thinking behind Altitude IT's Operational Heartbeat. The goal is not to promise that every suspicious message will be blocked. The goal is to make sure that a missed message does not have a clear, unobserved path to business compromise.

A useful question for your IT provider is not simply, “Do we have phishing protection?”

Ask what happens if a convincing phishing message gets through.