evening-computing-logo-60
Get in Touch

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.

Browse this guide

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

 

Why cyber attacks often start with ordinary activity

Many cyber attacks begin with something ordinary. A person may open an email, follow a link, approve a sign in request, install a tool, reuse a password, grant access to a cloud application, or contact what appears to be a genuine support service.

The problem is not always that someone has done something obviously reckless. Modern systems rely on email, browsers, mobile phones, cloud accounts, suppliers, plugins, remote access tools and public facing services. Each of those areas can become part of the security chain.

This is why small organisations should not think only in terms of one device or one product. A small weakness in one area may become more serious if it connects to accounts, shared files, email, websites, backups, payment systems or supplier access.

 

How phishing and fake messages lead to account 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.

Recent UK breach reporting continues to show phishing as a major 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

Why passwords, MFA, passkeys and session tokens all matter

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?

How fake support numbers and AI generated answers can mislead users

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?

Why suppliers, plugins and third party platforms can become part of the risk

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.

Recent WordPress plugin incidents show why this matters. A plugin that was previously trusted may become risky after a change in ownership or a compromised update path. A cloud application may also create exposure if it is granted broader permissions than necessary.

Supplier risk therefore needs to be reviewed as part of the wider security picture. Organisations should know which suppliers and third party tools have access, what permissions they hold, whether they are still needed, and how access would be removed if something went wrong.

For more detail, see our guides:

How do software supply chain attacks happen?

WordPress Hardening for Small Organisations

Why websites, hosting panels and public facing services need review

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

A website may look simple from the outside, but it may depend on a domain registrar, DNS provider, hosting provider, content management system, plugins, themes, email services, scripts, analytics tools, backup storage and administrator accounts.

Hosting control panels are also part of this chain. A cPanel or WHM vulnerability, for example, may be managed by the hosting provider rather than the website owner, but the organisation still depends on the provider applying patches and protecting administrative access.

The practical lesson is to know who manages each layer. Website security is not only about WordPress, plugins or visible content. It also includes DNS, hosting, account access, backups, provider patching, monitoring and recovery planning.

For more detail, see our guides:

Why DNSSEC matters and how DNS attacks can redirect internet traffic

Email validation and security explained

Why accountability and unmanaged devices matter

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 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.

How AI makes familiar cyber attacks faster and more convincing

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.

Why one security product is not enough

No single security product can cover every starting point. Antivirus may help with some malware. DNS filtering may help with some known unsafe domains. A firewall may reduce exposure. A password manager may reduce password reuse. Passkeys may make sign in harder to phish. Backups may help with recovery.

Each control has limits. A user may still be misled by a fake support number. A supplier may still be compromised. A browser session may still be abused. A plugin may still receive a harmful update. A cloud application may still hold excessive permissions.

Layered security is the more realistic model. Different layers reduce different parts of the risk. Some help prevent incidents, some help detect unusual activity, some help limit impact, and some support recovery if prevention fails.

For more detail, see our guide:

What is layered security and why does it matter?

 

What small businesses can review first

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.

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 check recovery. Backups should not depend only on the same account or platform they are protecting. Recovery methods, emergency contacts, domain access, admin access and supplier details should be known before an incident occurs.

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.

What this guide does not mean

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.

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

The practical message is that cyber security should be reviewed periodically. Prevention, detection, limitation of impact and recovery planning need to work together, and the right balance depends on the environment being protected.

Supporting references

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.

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