evening-computing-logo-60
Get in Touch

Why trusted services can still be used in cyber attacks

Many cyber attacks do not begin with an obviously suspicious website, unknown attachment or strange looking file. They often begin with something familiar: a cloud document link, a shared folder, a browser extension, a supplier portal, a website plugin, a login page, a support message, or an email that appears to come through a recognised service.

This guide explains why trusted services can still be used as part of cyber attacks. It does not mean those services are unsafe by default. It means that trust, convenience and connected access need to be understood and reviewed as part of a wider security approach.

The practical lesson is simple. A message, link, app, plugin or supplier tool should not be trusted only because it appears to involve a familiar platform. What matters is what the service is asking the user to do, what access it has, where the data is going, and whether the request makes sense in context.

Browse this guide

Use the links below to jump to the section most relevant to your question.

How trusted services normally work

Trusted services are useful because they make everyday work easier. They help people share documents, sign in to cloud systems, manage websites, automate tasks, install browser features, connect suppliers, protect accounts and move information between systems.

In normal use, these services reduce friction. A cloud document link lets someone share a file quickly. A browser extension adds a useful feature. A website plugin adds functionality. A supplier portal lets work continue without sending files back and forth by email. A single sign on account can give a user access to several business systems without separate passwords for each one.

The security issue is not that these services exist. The issue is that they often sit close to important data and accounts. A trusted service may be allowed to send email, host a page, read files, access browser activity, connect to a cloud account, update a website, use an API, or act on behalf of a user.

That trusted position is what attackers try to exploit.

How attackers abuse trust

Attackers often try to borrow the credibility of a service the user already recognises. Instead of sending a message from a completely unknown place, they may use a familiar brand name, a hosted page, a document sharing service, a form tool, a website builder, a supplier system, or a login page that looks similar to one the user has seen before.

The aim is usually to make the request feel routine. The user may be asked to verify an account, complete a security check, open a document, approve access, enter a password, provide a multi factor authentication code, install a browser extension, upload identification, join a call, or continue a conversation through another platform.

This can be more convincing than a simple fake email because the service involved may be real. The abuse may sit around the service rather than inside the service itself. For example, the service may be used to send a notification, host a file, redirect a user, collect form responses, or make the link look less suspicious.

In practice, the danger is not only the name of the platform. The danger is the action being requested.

Common places where trusted services are abused

Trusted service abuse can appear in many ordinary areas of technology. Small organisations may not use all of these, but most rely on several of them every day.

Common examples include:

  • Email platforms used to send messages that appear more believable because they come through a recognised sending service.
  • Cloud document links that lead users towards fake login pages, unsafe downloads or requests for sensitive information.
  • Website builders and hosting platforms used to present convincing pages that imitate a known brand or support portal.
  • Browser extensions that request broad permissions or collect more browsing related data than the user expects.
  • Website plugins and software updates that become risky after a change in ownership, compromise, or unsafe update path.
  • Single sign on accounts that provide access to several cloud services after one identity is compromised.
  • Supplier portals, support tools and third party applications that retain access after the original need has passed.
  • Automation services, API keys and tokens that move data or perform actions without a person approving each step.

These are not unusual technologies. They are the normal tools that make modern work possible. That is why they need periodic review rather than blind trust.

Why this can be difficult to spot

Trusted service abuse can be difficult to spot because nothing may look broken at first. The browser may open normally, the email may be delivered successfully, the link may use HTTPS, and the page may be hosted by a recognised platform.

Users are often trained to look for obvious signs, such as bad spelling, strange attachments or unfamiliar web addresses. Those checks are still useful, but they are not enough on their own. A modern attack may use a professional looking page, a legitimate hosting provider, a familiar workflow tool or a message that appears to match a real business process.

AI can make this more difficult because fake messages, support instructions, account warnings and impersonation attempts can look more polished and natural than older scams. The important question is still not only whether the service looks familiar, but what action is being requested, whether it was expected, and whether it can be verified through a trusted source.

This also explains why technical controls and user judgement need to work together. Filtering, browser protections, email security, DNS controls, account monitoring and staff awareness each reduce part of the risk, but none of them should be treated as complete protection on their own.

The safest question is not only “Do I recognise this service?” It is also “Is this request expected, proportionate and verified through a trusted source?”

What to check before trusting a request

When a message, page or link appears to involve a familiar service, it is worth pausing to check the request itself. The platform name may be familiar, but the action being requested may still be unusual.

Before entering details, approving access, uploading documents, installing an extension, or following account recovery instructions, check whether the request was expected and whether it came through a normal channel. Where possible, verify it separately through the official website, app, account portal, or a known contact rather than relying only on the link or message in front of you.

This is especially important where the request involves passwords, multi factor authentication codes, payment details, document access, administrator approval, recovery information, identity documents, or permission to install something in the browser.

A useful real world example is the use of fake CAPTCHA pages on compromised WordPress websites. In those cases, the website may appear familiar or legitimate, but the visitor may be asked to complete a fake verification step that is actually designed to make them run unsafe commands or install malware.

For a more detailed explanation, see our related guide:

Fake CAPTCHA Malware on WordPress Websites Explained

Real incidents that show the pattern

Public reporting has shown several examples of this wider pattern. The details vary, but the common theme is that attackers use trusted systems, familiar workflows or approved access to make an attack more believable or more effective.

One reported phishing campaign targeting Facebook Business account owners used Google AppSheet as a relay and then directed users towards fake pages and related infrastructure. The campaign reportedly used account disablement, copyright complaints, verification reviews and similar account related pressure to encourage users to provide credentials, two factor authentication codes or identity information.

Other reporting has described voice phishing attacks where criminals impersonated IT help desk staff and directed users to fake single sign on pages. Once credentials and authentication codes were captured, attackers could move into connected software services such as email, shared files, CRM platforms and other business systems.

Browser extension reporting has also shown why trusted add ons need review. Some extensions may not behave like obvious malware but may still collect or share browsing related data under their stated terms. That makes extension review a privacy and account security issue, not only a malware issue.

Website and plugin incidents show a similar lesson. A plugin, control panel or hosting service may be trusted because it is already part of the environment, but that trust can become a weakness if updates, ownership, credentials, supplier access or monitoring are not reviewed.

These examples do not mean every trusted service is unsafe. They show why trusted access should be understood, limited and reviewed.

Why this matters for small organisations

Small organisations often depend on a mixture of cloud accounts, shared documents, supplier tools, websites, payment systems, email, browser based services, remote access tools and personal devices used for work. That creates convenience, but it also means one trusted account or service can affect several areas at once.

For example, a compromised email account may expose messages, reset links, supplier conversations and document notifications. A compromised single sign on account may open access to several connected systems. A browser extension with broad permissions may sit close to signed in sessions. A supplier tool may retain permissions long after a project is finished.

This is why cyber security should not be reviewed only as a device problem. The wider question is how people, accounts, suppliers, cloud services, websites, browsers and data movement connect together.

Where several systems depend on the same account, supplier or workflow, that dependency should be visible before an incident occurs.

How to review trusted access in practice

A practical review does not need to assume every service is dangerous. It should identify where trust has been granted and whether that trust is still necessary, proportionate and recoverable.

Useful review questions include:

  • Which cloud accounts have administrator access?
  • Which third party applications have been approved in Microsoft 365, Google Workspace or other cloud platforms?
  • Which browser extensions are installed and what permissions do they have?
  • Which suppliers can access websites, DNS, hosting panels, backups, cloud accounts or support tools?
  • Which apps, scripts, API keys or tokens can read, move or modify data?
  • Are old users, former staff, previous suppliers or unused tools still present?
  • Are inbox rules, forwarding rules and recovery methods reviewed for important accounts?
  • Are backups separate from the accounts and platforms they are protecting?
  • Is there a known process for revoking access if a supplier, account or device becomes a concern?

The aim is not to remove every useful tool. The aim is to avoid unmanaged trust.

For many small organisations, the first step is simply to make the access visible. Once access is visible, it becomes easier to remove what is no longer needed, reduce permissions where possible, improve sign in protection, and plan recovery before there is a problem.

What this guide does not mean

This guide does not mean that cloud services, browser extensions, website plugins, document links, supplier portals or automation tools should be avoided by default. These services are often necessary and useful.

It also does not mean that small organisations need enterprise level security processes for every decision. The appropriate level of review depends on the systems involved, the sensitivity of the data, the number of users, and the impact if access is misused.

This guide is not a permanent checklist. Technology changes, suppliers change, platforms introduce new protections, attackers adapt, and old controls may become less effective over time.

The practical message is that trusted services should be included in layered security. Account protection, supplier access, browser controls, email security, DNS filtering, monitoring, backup separation and recovery planning need to work together.

Related guides

The following guides provide more detail on related areas of risk and practical review.

Supporting references

The following sources provide background for the examples and themes discussed in this guide. They are included to support the factual context rather than to suggest that every organisation faces the same level of risk.

Further Guidance and Support

This guide forms part of a broader layered security approach. For structured guidance on security and resilience planning, see our Security and Resilience page.

For information about practical implementation and ongoing support, you can review our IT services and local IT support coverage across London, Hertfordshire, and Essex.

Return to all guides

Author
Elías Sánchez
IT Support Consultant
Evening Computing
London, United Kingdom

This guide was prepared by Elías Sánchez with research and drafting assistance from AI tools. All technical content has been reviewed and adapted for clarity and accuracy.

Last reviewed
07 May 2026