How do cyber attacks usually start in small businesses?

Cyber risk in small businesses often grows before any incident is visible. It may begin with ordinary activity or ordinary decisions: a convincing email, a reused password, an exposed online service, a supplier account, fake support details, a browser session, a mobile message, a personal device used for work, or a system that has not been reviewed for some time.

This guide uses public breach reporting, vendor advisories and documented examples to explain common starting points for cyber attacks, without treating them as the only possible ways attacks can begin. The aim is to show why layered security matters in practice and why prevention, detection, limitation of impact and recovery planning need to work together.

The guide is not a complete list of every possible attack method. It focuses on common and well documented starting points that are relevant to small organisations, professionals and individuals who rely on email, websites, cloud services, mobile devices, suppliers and shared systems.

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

• Why cyber attacks often start with ordinary activity
• How phishing and fake messages lead to account access
• Why passwords, MFA, passkeys and session tokens all matter
• How fake support numbers and AI generated answers can mislead users
• Why suppliers, plugins and third party platforms can become part of the risk
• Why websites, hosting panels and public facing services need review
• Why accountability and unmanaged devices matter
• How AI makes familiar cyber attacks faster and more convincing
• Why one security product is not enough
• What small businesses can review first
• What this guide does not mean
• Supporting references
• Need help with something covered in this guide?
• Further Guidance and Support

Many cyber attacks begin with something that looks ordinary. A person may open an email, follow a link, approve a sign in request, install a tool, grant access to an application, contact what appears to be genuine support, or simply use a service that the organisation already trusts.

The starting point and the eventual impact are often separated by several steps:

Ordinary activity or trusted service
↓
A weakness, deception or compromised component is encountered
↓
An account, device, application or service gains unintended access
↓
That access connects to other systems or information
↓
The effect becomes a wider business problem

The weakness does not always involve somebody making an obvious mistake. Modern organisations depend on browsers, operating systems, cloud services, suppliers, plugins, endpoint protection, network services and other complex software. Even where these are supported and fully updated, vulnerabilities may exist that have not yet been discovered or for which an effective fix is not yet available.

This is why security should not be judged only by whether one device is patched or one security product is installed. A weakness becomes more significant when it connects to email, shared files, websites, backups, payment systems, administrative accounts or supplier access.

Phishing remains one of the most common ways attackers try to gain access to accounts or information. The message may arrive by email, text message, chat message, social media, fake login page, or a link that appears to come from a familiar organisation.

The aim is often to make the user take an action. That action may be entering a password, approving a sign in prompt, opening an attachment, calling a number, making a payment, or visiting a page that collects account details.

UK breach reporting has repeatedly identified phishing as an important issue for businesses. This matters because phishing is not only a technical problem. It relies on timing, trust, pressure, familiarity and the fact that people are trying to get work done.

A familiar platform does not automatically make a message safe. Some phishing campaigns use trusted services, document links, website builders, workflow tools or cloud hosted pages to make the request appear more credible. A warning about an account closure, copyright complaint, verification review, recruitment message or security alert should still be verified through a separate trusted source before entering passwords, approving sign in prompts, uploading identification, or sharing recovery information.

Email validation also matters because fraud often relies on trust in familiar domain names. If SPF, DKIM and DMARC are missing or weakly configured, criminals may find it easier to send messages that appear to come from an organisation’s domain, even though the messages were not authorised by that organisation. That can contribute to invoice fraud, payment redirection, fake login requests and other impersonation attempts.

SPF helps publish which sending systems are allowed to send email for a domain. DKIM adds a cryptographic signature to help prove that a message was authorised and has not been altered during delivery. DMARC ties SPF and DKIM to the visible From address and tells receiving servers what to do when a message fails validation. A DMARC policy of reject is the strongest anti spoofing position, but it should normally be reached through a staged process so legitimate email is not accidentally disrupted.

A Toronto Police investigation into mobile SMS blasters showed that fraudulent messages may sometimes be delivered through rogue mobile network equipment rather than ordinary messaging systems. Police reported tens of thousands of affected devices and more than 13 million network disruptions, with possible temporary impact on access to 911. This does not mean every text message is dangerous, but it shows why familiar looking messages still need careful verification.

For more detail, see our guide:

Email validation and security explained

Account access is one of the most important parts of modern security. A business may use cloud email, shared files, websites, payment platforms, supplier portals, remote support tools and administrative accounts. If one important account is misused, the effect may spread beyond one person.

Weak or reused passwords create risk because a breach at one service may be used to attempt access elsewhere. Multi factor authentication reduces that risk, but not every method gives the same level of protection. Passkeys and modern security keys can make the sign in process much more resistant to phishing because the user is not typing a reusable password into a website.

Even stronger sign in does not remove every other risk. Attackers may try to steal session cookies, abuse device code flows, persuade a user to approve an application, or make changes to account recovery settings. For that reason, authentication should be reviewed alongside device security, browser security, app permissions, recovery methods and monitoring.

Where a business uses single sign on, one compromised identity may provide access to several connected services. Attackers may try to impersonate IT support, direct users to fake sign in pages, capture MFA codes, register a new device, change recovery options, or create inbox rules to hide security alerts. Account security should therefore include monitoring for unusual device registration, suspicious inbox rules, unexpected application consent, changes to recovery methods, and changes to privileged roles, not only password strength.

Access should also follow the principle of least privilege. Administrative, domain level or sensitive permissions should be given only where they are genuinely needed, and to the minimum number of users. This reduces the impact if an account is compromised, misused or used by mistake.

For more detail, see our guide:

Are passkeys and security keys the same thing?

Not every attack begins with a malicious file or a fake invoice. Some begin when a person looks for help. A user may search for a customer service number, click an advert, read a forum post, ask an AI tool for support details, or respond to a message that appears to come from a known provider.

Fraudsters may try to place fake phone numbers, fake support pages or misleading instructions where users are likely to find them. The risk is greater when the user is under pressure and wants to fix a payment, account, delivery, banking, broadband, email or device problem quickly.

Virgin Media O2 has warned that fake customer service numbers can be surfaced by AI tools and search engines. Microsoft also warns that technical support scams may use phone calls, fake warnings, spoofed caller ID, remote access requests or payment pressure.

For support requests involving passwords, recovery codes, remote access, payments or account changes, contact details should be verified through the provider’s official website, app, bill, customer portal or known documentation.

For more detail, see our guide:

Can websites in Google search results still be dangerous?

Small organisations often depend on suppliers and third party platforms. These may include website plugins, cloud applications, browser extensions, payment providers, backup systems, email services, hosting platforms, outsourced support tools and AI tools and services.

This does not mean third party services are unsafe by default. The issue is the amount of trust and access given to them. A service may hold delegated permissions, API access, administrator rights, customer data, email access, file access or the ability to change website behaviour.

An attack may also begin through an account or feature that is genuinely part of the platform. Activity performed through a valid account can appear more routine than activity coming from an obviously unknown source. This is why account type, permissions, behaviour and context all matter, not only whether the platform itself is recognised.

Documented WordPress plugin incidents illustrate this problem. A plugin that was previously trusted can become risky after a compromised update path, a security weakness, a change in control, or another failure within the software supply chain. A cloud application can similarly create exposure if it is compromised or has been granted broader permissions than it genuinely needs.

Supplier risk therefore needs to be reviewed as part of the wider security and continuity picture. Organisations should know which suppliers and third party tools have access, what permissions they hold, whether that access is still needed, how it could be removed or contained if something went wrong, and how an important function or information would be recovered if the supplier or service became unavailable.

For more detail, see our guides:

How do software supply chain attacks happen?

WordPress Hardening for Small Organisations

Public facing systems deserve particular attention because they can be reached from outside the organisation. These may include websites, hosting control panels, DNS portals, VPNs, remote access services, email administration portals, supplier dashboards and cloud administration interfaces.

A simple website may depend on a much larger technical chain:

Domain registrar
↓
DNS provider
↓
Hosting platform
↓
Content management system
↓
Plugins, themes and scripts
↓
Administrator accounts and connected services

A weakness at any one of these layers can affect the service above it.

Supported software and regular security updates remain important because they remove many known vulnerabilities. However, public facing systems can also be exposed to vulnerabilities that have only just been discovered, weaknesses for which a patch is not yet available, configuration errors, compromised accounts or failures within a supplier’s own infrastructure.

Some layers may also be managed by somebody else. A vulnerability in a hosting control panel, cloud platform or network service may require action from the provider rather than the website owner. The organisation therefore depends not only on its own patching, but also on the security and response processes of its suppliers.

A useful review asks:

Who manages this layer?
↓
How is it protected and monitored?
↓
Who is responsible for applying security fixes?
↓
How would access be contained if the layer were compromised?
↓
How would the service be restored or continued if it became unavailable?

Website and public service security therefore includes DNS, hosting, software updates, account protection, monitoring, backups, configuration records and recovery planning. No individual layer should be assumed to make the complete service invulnerable.

For more detail, see our guides:

Why DNSSEC matters and how DNS attacks can redirect internet traffic

Email validation and security explained

Cyber attacks do not only start because a product is missing or a setting is wrong. In many small organisations, risk increases because nobody clearly owns the decision about which devices, accounts, suppliers and services are allowed to access business data.

This becomes especially important where staff use personal laptops, home computers or personal phones to access company email, cloud files, supplier portals or customer information. If those devices are not managed, the organisation may not know whether they are encrypted, updated, protected by endpoint security, shared with family members, or configured to prevent local data from being copied or synchronised.

A personal device may appear convenient, but it can become a weak point if it stores business data, browser sessions, cached credentials or downloaded files without the same controls expected on a work device. The issue is not that every personal device is unsafe. The issue is that business data should not depend on devices that the organisation cannot assess, protect, update, recover or remove access from.

Convenience can also create risk when temporary arrangements become permanent. A basic password used during setup, an unlocked screen, an unmanaged personal device, or a password written where others can see it may not feel like a major issue at the time. The risk increases when the device or service later becomes part of normal work without the security settings being reviewed.

Accountability also applies to guest accounts, trial accounts, contractors, suppliers and external collaborators. The organisation should know who can create these accounts, what access they receive, whether unusual activity is monitored and when the access should expire.

Accountability means these decisions should be visible and owned. Organisations should know which devices are allowed, which accounts have access, which suppliers hold permissions, what security requirements apply, and who is responsible for acting when a risk is identified.

AI does not create a completely separate kind of cyber risk. It can make familiar scams, phishing messages, fake support instructions, impersonation attempts and research faster, cheaper, more personalised and more convincing.

A fake email, support message, login page, supplier request or phone script may now be easier to prepare and harder to recognise quickly. The wording may be more natural, the timing may feel more believable, and the message may appear to relate more closely to the person or organisation being targeted.

The risk may still involve familiar systems rather than something obviously suspicious. An attacker may try to misuse a normal business account, a supplier relationship, a public facing service, a browser session, a cloud permission, or a third party application that already has access.

This is why the practical response should not be panic about AI. It should be better visibility and control over the areas that already matter: account security, supplier access, browser safety, device management, public facing systems, monitoring, backups and recovery planning.

AI can change the speed and credibility of some attacks, but it does not remove the need for careful configuration, clear ownership, least privilege, staff awareness and tested recovery.

No single security product can cover every way an incident may begin.

An antivirus or Endpoint Protection Platform may detect malicious software or suspicious behaviour. DNS filtering may reduce connections to some harmful destinations. A firewall can restrict network access. Browser protections can warn about some unsafe pages and downloads. MFA, passkeys and security keys can strengthen account access. Email security can reduce some malicious or impersonated messages. Backups can support recovery.

Each of those controls answers a different question:

Can this connection be allowed?

Should this domain be reached?

Does this behaviour look malicious?

Is this person or device authorised?

Can this message be trusted?

Can the organisation recover if the earlier controls fail?

None of them can answer every question.

This matters particularly because software and digital services are complex. Security products themselves may contain software defects, new attacks may not yet be recognised, legitimate services may be abused, and vulnerabilities can exist before an effective patch becomes available.

Layered security therefore needs to cover more than prevention:

Prevent → Detect → Contain → Recover → Learn → Improve

Prevent where practical.

Detect unusual activity when prevention is not enough.

Contain an incident so that one problem does not become a wider one.

Recover important systems, information and access.

Learn how the incident occurred and what was affected.

Improve the controls and procedures before returning to normal operation.

The aim is not to build a collection of security products and assume the organisation is protected. The aim is to understand which risks each control reduces and what happens when one layer does not work as expected.

For more detail, see our guide:

What is layered security and why does it matter?

A useful starting point is to identify the systems that would cause the most disruption if they were unavailable, misused or compromised. These often include email, Microsoft 365 or Google Workspace, shared files, websites, payment systems, backups, accounting systems, DNS, hosting, email validation records and key supplier portals.

A practical review can then follow a simple path:

What do we depend on?
↓
Who owns and administers it?
↓
How is access protected?
↓
How is unusual activity detected?
↓
How could access be contained?
↓
How would we continue or recover if it failed?

This helps move the review away from simply asking “What security products do we have?” and towards understanding how the organisation actually operates.

Some of these systems can be reached from the internet, such as websites, hosting panels, DNS portals, remote access services, email administration portals, supplier dashboards and cloud administration consoles. These should have clear ownership, strong sign in protection, regular updates where applicable, and a known recovery path if access is lost or misused.

Email review should include both sender validation and transport protection. SPF, DKIM and DMARC help reduce domain spoofing, while TLS and MTA-STS help protect email while it moves between mail servers. These controls solve different problems, so one should not be treated as a replacement for the other.

The next step is to review who has access. Important questions include which accounts are administrators, whether MFA or passkeys are in use, whether passwords are reused, which third party apps have been approved, and whether former staff, old suppliers or unused tools still have access.

It is also important to review recoverability and business continuity. Backups should not depend only on the same account, device or platform they are intended to protect. Recovery accounts, domain access, administrative credentials, supplier details and emergency contacts should be known before an incident occurs.

Recovery planning should include restorable backups, sufficient logging and the information needed to rebuild or regain control of important services. Backups help restore systems and information. Logs help establish how access occurred, what may have been affected and which accounts, sessions, tokens or integrations may need to be revoked. Configuration records and documented supplier arrangements can also be important where the problem involves infrastructure or a service that cannot simply be restored from a file backup.

For business critical services, the review should also ask what the organisation would do while recovery is taking place. A backup helps restore information, but continuity may depend on alternative communications, replacement equipment, another internet connection, emergency administrative access or a temporary way of continuing an essential process.

These checks do not guarantee protection. They help reduce avoidable exposure and make it easier to respond if something unexpected happens.

Where these checks involve shared systems, supplier access, Microsoft 365, websites, backups or network infrastructure, the issue may belong within wider IT support and security and resilience planning rather than a single device fix.

This guide does not mean that every organisation faces the same level of risk. A small office, charity, professional practice, school, home business and ecommerce site may all depend on different systems and suppliers.

It also does not mean that every email, plugin, cloud service, AI tool, text message or supplier is unsafe. The purpose is to show why these areas should be included in the wider security view rather than treated as separate from it.

The examples in this guide illustrate broader attack paths rather than providing a permanent list of threats. Technology changes, attackers adapt, suppliers change, new vulnerabilities are discovered and platforms introduce new protections.

The enduring principle is therefore to understand where trust and dependency exist, which controls protect them, what their limitations are and how the organisation would respond if one of those controls failed.

Cyber security should be reviewed periodically. Prevention, detection, containment, recovery and business continuity need to work together, with the balance determined by the systems and information the organisation actually depends upon.

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

• UK Government: Cyber Security Breaches Survey 2025 to 2026
• National Cyber Security Centre: Annual Review 2025
• Microsoft: Digital Defense Report 2025
• ICO: Data protection self assessment for medium businesses
• ICO: Guide to accountability and governance
• Virgin Media O2: warning about fake customer service numbers surfaced by AI tools and search engines
• Toronto Police Service: Project Lighthouse SMS blaster fraud investigation
• cPanel: CVE-2026 41940 cPanel and WHM security update
• Anchor Hosting: WordPress plugin supply chain incident
• TechCrunch: WordPress plugin backdoor incident
• Financial Times: How cyber security is changing in the age of AI
• Microsoft: Protect yourself from tech support scams
• Evening Computing: What is layered security and why does it matter?

A guide can explain the issue and outline useful checks, but some situations need the actual device, account, service, website, network or supplier arrangement to be reviewed. Evening Computing can help review what is happening and advise on suitable next steps before changes are made.

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

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
17 August 2026