How Hackers Break Into Your Company Website: The Full Attack Chain

Most business owners think of hacking as something that happens to banks, governments, or tech giants. The reality is different. Every day, thousands of small and medium company websites get compromised by attackers who never specifically chose those targets. They found them the same way Google finds websites: by scanning the entire internet.

This article walks through the exact steps an attacker takes to compromise a business website. Not theory. Not Hollywood fiction. The actual, repeatable process that security professionals see in incident after incident. Understanding this chain is the first step toward breaking it.

Step 1: Reconnaissance - Gathering Information About Your Site

Before an attacker touches your website, they collect information about it. This phase is called reconnaissance, and it requires zero interaction with your server. Everything is gathered from publicly available sources.

WHOIS Lookups

The WHOIS database stores registration details for every domain name. An attacker queries it to find out who registered your domain, when, which registrar you use, and sometimes your name, email, and phone number. If your domain registration is about to expire, that is also visible and exploitable (expired domains can be re-registered by anyone).

In Switzerland, domains ending in .ch are managed by SWITCH. The WHOIS data for .ch domains is more restricted than for .com domains, but still reveals the registrar, registration date, and name server configuration.

DNS Enumeration

DNS records are public by design. An attacker queries your DNS to find:

• A/AAAA records: The IP addresses of your web server. This tells them your hosting provider and sometimes reveals other sites on the same server.
• MX records: Your email infrastructure. If you use Google Workspace or Microsoft 365, this is visible here.
• TXT records: SPF, DKIM, and DMARC configurations (or their absence). Also reveals third-party services you use (verification records for Google, Facebook, etc.).
• Subdomains: Tools like subfinder, amass, or certificate transparency logs reveal subdomains. This often turns up forgotten staging sites, admin panels, old test environments, and development servers that nobody remembered to take offline.

Shodan and Censys

Shodan is often called "the search engine for the internet of things." It continuously scans every public IP address and indexes what it finds: open ports, running services, software versions, SSL certificate details, HTTP response headers. An attacker types your domain or IP into Shodan and immediately sees your web server software and version, your PHP version, whether you run an outdated OpenSSH, what other ports are open, and what services respond on them.

This is not hacking. This is looking at publicly available information that your server broadcasts to everyone who asks. Shodan just makes it searchable.

Wappalyzer and Technology Fingerprinting

Wappalyzer is a browser extension (and API) that identifies the technology stack behind any website. Visit a site, and it tells you the CMS (WordPress 6.1, Joomla 4.2, Drupal 10), the JavaScript frameworks, the analytics tools, the server software, and the plugins. BuiltWith does the same thing at scale.

Why does this matter? Because every technology has known vulnerabilities tied to specific versions. If your site runs WordPress 5.8 with Contact Form 7 version 5.3.2, an attacker already knows every CVE (Common Vulnerabilities and Exposures) that applies. They do not need to guess. They look it up in public databases like the National Vulnerability Database (NVD) or WPScan's vulnerability database.

Google Dorking

Google indexes more of your website than you might think. Attackers use advanced search operators to find exposed files:

• site:yourcompany.ch filetype:sql - Finds SQL database dumps accidentally left on your server.
• site:yourcompany.ch filetype:log - Finds log files that may contain passwords, API keys, or internal paths.
• site:yourcompany.ch inurl:admin - Finds admin login pages.
• site:yourcompany.ch inurl:wp-content/uploads - Lists every file in your WordPress uploads directory.
• site:yourcompany.ch "index of" - Finds directories with directory listing enabled, exposing file structures.

None of this requires any special tools. Just a web browser and Google.

The Wayback Machine and Cached Pages

The Internet Archive stores historical snapshots of websites. Attackers use it to find old pages that have been removed but may still exist on the server, old site structures that reveal naming conventions, and previous versions of the site that ran different (and possibly still active) software.

Step 2: Automated Vulnerability Scanning

After reconnaissance, the attacker has a detailed map of your technology stack. Now they scan for specific vulnerabilities. This is where things get automated, and it is why the "we are too small to be a target" argument falls apart.

How Automated Scanners Work

Tools like Nikto, WPScan, Nuclei, and Acunetix take a URL as input and test it against hundreds or thousands of known vulnerabilities. They check for missing security headers, default credentials on admin pages, known vulnerabilities in the detected CMS version, known vulnerabilities in detected plugins, exposed configuration files, directory traversal possibilities, SQL injection points, and cross-site scripting opportunities.

A full scan takes minutes. Automated botnets run these scans continuously across every IP address on the internet. Your site is being scanned right now, whether you know it or not. The logs of any web server show a constant stream of automated requests probing for /wp-login.php, /administrator, /.env, /phpinfo.php, and dozens of other common paths.

The Botnet Scanning Economy

This is not one person sitting at a computer choosing your site. Criminal organizations operate botnets (networks of compromised computers) that scan millions of sites per day. When a bot finds a vulnerability, it reports back. A human operator then decides which compromised sites are worth exploiting further.

The scanning is indiscriminate. A bakery in Bellinzona gets scanned with the same frequency as a bank in Zurich. The difference is that the bank has a security team watching those scans and responding. The bakery does not.

CMS-Specific Scanners

WordPress sites face particularly intense scanning because WordPress powers roughly 40% of all websites. WPScan has a database of over 40,000 known vulnerabilities in WordPress core, themes, and plugins. When a new vulnerability is disclosed, exploit code often appears within hours, and automated scanners add it to their rotation within days.

See our detailed analysis in WordPress vulnerabilities: what changed and what still breaks.

Step 3: Exploitation - Getting In

Scanning found a vulnerability. Now the attacker exploits it. The specific method depends on the vulnerability, but here are the most common ones we see in Swiss SME website compromises.

SQL Injection (SQLi)

SQL injection happens when user input (from a search box, login form, URL parameter, or contact form) is passed directly to a database query without proper sanitization. The attacker inserts SQL commands where the application expects regular text.

Consider a login form that checks credentials with a query like:

SELECT * FROM users WHERE username = 'INPUT' AND password = 'INPUT'

If the attacker enters ' OR '1'='1 as the username, the query becomes:

SELECT * FROM users WHERE username = '' OR '1'='1' AND password = ''

Since '1'='1' is always true, the database returns all users, and the attacker is logged in as the first user in the table, which is typically the administrator.

This is the simplified version. Real-world SQLi is more sophisticated and can extract entire databases, modify data, create new admin accounts, or even execute operating system commands through the database server.

Cross-Site Scripting (XSS)

XSS allows an attacker to inject JavaScript code into web pages viewed by other users. There are three types:

• Reflected XSS: The malicious script is embedded in a URL. When someone clicks the link, the script executes in their browser. Common in search functionality and error pages.
• Stored XSS: The malicious script is permanently stored on the server (in a database, comment field, or user profile). Every visitor who views that page executes the script. This is more dangerous because it does not require the victim to click a special link.
• DOM-based XSS: The vulnerability is in the client-side JavaScript code rather than the server-side code.

What can an attacker do with XSS? They can steal session cookies (and take over user accounts), redirect visitors to phishing pages, inject cryptocurrency miners, modify page content (showing fake payment forms, for example), and log keystrokes.

File Upload Vulnerabilities

Many websites allow file uploads: profile pictures, documents for contact forms, portfolio items. If the upload functionality does not properly validate file types, an attacker can upload a PHP file disguised as an image. When they access that file through the web server, the PHP code executes, and they have remote code execution on your server.

This is one of the most common attack vectors we see in Ticino business websites. A contact form that allows attachments, a portfolio section with image uploads, a job application form that accepts CV files. Any of these can become an entry point if the upload validation is insufficient.

Remote Code Execution Through Plugins

CMS plugins are the number one attack vector for website compromises. A single vulnerable plugin can give an attacker complete control over your website and, depending on the server configuration, the entire server.

The pattern repeats: a researcher or attacker discovers a vulnerability in a popular plugin. A CVE is published. Within days (sometimes hours), exploit code is available. Automated scanners add the exploit to their arsenal. Every website running the vulnerable version is now a target.

Plugins for contact forms, SEO optimization, page builders, e-commerce, and caching have all had severe vulnerabilities. The problem is compounded when businesses use plugins that are no longer maintained by their developers. No maintainer means no patches.

Authentication Bypass and Brute Force

If the admin panel is accessible from the internet (and in most business websites it is), attackers will try to brute-force the login. They use credential stuffing (trying username/password combinations leaked from other breaches) and dictionary attacks. Without rate limiting, account lockout, or multi-factor authentication, it is a matter of time before they get in.

We frequently find admin panels for Swiss business websites at predictable URLs like /wp-admin, /administrator, or /admin with no additional protection. See our article on exposed admin pages and how to protect them.

Step 4: Persistence - Staying In

Getting in is one thing. Staying in is another. Attackers want persistent access that survives password changes, plugin updates, and even partial cleanups.

Web Shells

A web shell is a script (usually PHP) that provides a web-based interface to the server. It looks like a normal file in your website directory but gives the attacker a command line through their browser. They can browse files, edit configurations, access the database, upload more tools, and pivot to other systems on the network.

Web shells are small. Some are a single line of PHP code. They are often hidden in directories with thousands of legitimate files (like wp-content/uploads/2022/03/) and given names that look like legitimate WordPress files (class-wp-theme-compat.php). Without knowing what files should be there, you will not notice.

Backdoor Accounts

The attacker creates a new administrator account in your CMS with a name that looks legitimate (wp_maintenance, system_update, support_admin). Even if you discover the intrusion and change all passwords, this account persists. If you do not audit your user list, you will not notice it.

Modified Core Files

Attackers sometimes modify CMS core files to include their backdoor code. The function that loads on every page request gets a few extra lines that check for a specific parameter and, if present, execute commands. This persists through password changes and plugin updates, and it is not found by simply looking at your user list or checking for new files.

Cron Jobs and Scheduled Tasks

On the server level, attackers may add cron jobs that periodically check if their web shell is still present and re-create it if it has been deleted. This is why a superficial cleanup often fails: you remove the web shell, but the cron job puts it back within the hour.

Step 5: Data Exfiltration and Monetization

Now the attacker has persistent access. What do they do with it?

Data Theft

Customer databases, email lists, personal information, payment details (if stored), internal documents, login credentials for other services. Under the Swiss new Federal Act on Data Protection (nLPD) and GDPR, a breach involving personal data triggers notification obligations and potential fines.

SEO Spam Injection

One of the most common outcomes we see in compromised Swiss business websites is SEO spam. The attacker injects hidden links and pages into your site that promote pharmaceutical products, gambling sites, or counterfeit goods. Your visitors may not see it (the spam is often cloaked and only visible to search engine crawlers), but Google sees it and penalizes your site.

The business owner often does not notice for months. They just see their search rankings gradually dropping and wonder why. By the time they find the injected content, the SEO damage takes 6 to 12 months to recover from.

Cryptojacking

The attacker injects JavaScript code that mines cryptocurrency using your visitors' browsers. Your website slows down, visitors complain, but there is no obvious defacement. The attacker earns cryptocurrency quietly while your site performance degrades.

Ransomware and Extortion

In more targeted attacks, the attacker encrypts your website files and database and demands payment for the decryption key. For businesses that rely on their website for sales or operations, this can be devastating.

Lateral Movement

If your website server is connected to your internal network (which is more common in small businesses than you might think, especially with on-premise hosting), the attacker uses it as a jumping point to reach your internal systems: file servers, email, databases, accounting software.

Why "Too Small to Be a Target" Is Wrong

Let us be very specific about why this thinking is wrong:

1. Scanning is automated. Botnets scan every IP address. They do not select targets. They find vulnerabilities.
2. Exploitation is automated. Once a vulnerability is found, the exploit runs automatically. No human decides whether your company is "worth" attacking.
3. Small sites are easier. They have fewer defenses, less monitoring, and slower response times. Attackers face less resistance.
4. Your site has value even if your data does not. Your server resources (for hosting phishing pages, sending spam, mining cryptocurrency), your domain reputation (for sending credible phishing emails), and your SEO authority (for injecting spam) all have monetary value to attackers.

Data from the Swiss NCSC confirms this. The majority of reported cyber incidents in Switzerland come from small and medium businesses.

The Web Agency Problem

Many Swiss SMEs outsource their website to a local web agency. This is reasonable. The problem is that most web agencies are design and marketing companies, not security companies. They build attractive, functional websites, but security is not their core competency.

Common agency shortcomings we find during security assessments in Ticino:

• No security headers configured: CSP, HSTS, X-Frame-Options are missing entirely.
• Default admin URLs: WordPress admin at /wp-admin with no IP restriction or additional authentication.
• Unused plugins left active: Plugins installed during development but never removed. Each one is an additional attack surface.
• No maintenance contract: The site is built, delivered, and never updated again. Within a year, the CMS, PHP version, and plugins are all out of date with known vulnerabilities.
• Shared hosting with no isolation: Multiple client websites on the same server with no proper isolation. One compromised site leads to all sites being compromised.
• FTP instead of SFTP: Credentials transmitted in plain text. Anyone on the same network can intercept them.
• No input validation: Forms accept any input without server-side validation, opening the door to SQLi, XSS, and other injection attacks.

This is not about blaming agencies. It is about recognizing that building websites and securing websites are different skill sets. If your agency does not offer security services, you need someone who does.

How to Break the Attack Chain

Every step in the attack chain can be disrupted:

Attack Phase	Defensive Measure
Reconnaissance	Minimize information disclosure. Hide server version headers. Use WHOIS privacy. Remove unnecessary DNS records. Take down unused subdomains.
Scanning	Web Application Firewall (WAF) to block automated scanners. Rate limiting. Fail2ban for repeated probing.
Exploitation	Keep everything updated. Server-side input validation. Security headers (CSP blocks XSS). Restrict file uploads. Disable unused features.
Persistence	File integrity monitoring. Regular user account audits. Restrict file write permissions. Monitor cron jobs.
Exfiltration	Network monitoring. Database access logging. Egress filtering. Regular security scans for injected content.

Real-World Examples from Swiss Businesses

Without naming specific companies (for obvious reasons), here are patterns we have observed during incident response engagements with Swiss SMEs:

Case 1: A Ticino Service Company

A service company in Ticino had their WordPress site compromised through an outdated Contact Form 7 plugin. The attacker uploaded a web shell through the file upload vulnerability, then injected SEO spam across 800 pages. The company did not notice for five months. By the time they found it, Google had flagged the site as potentially harmful, their organic traffic had dropped 70%, and their business email was being flagged as spam because the domain reputation was damaged. Recovery took nine months.

Case 2: A Lugano Professional Practice

A professional practice in Lugano used a custom-built website with a patient contact form. The form had no input sanitization. An attacker used SQL injection to extract the entire database, including patient names, email addresses, and appointment details. This constituted a data breach under the nLPD, requiring notification to the FDPIC and affected individuals. The reputational damage was significant.

Case 3: An E-commerce Site in the Sopraceneri

A small online shop running an outdated version of WooCommerce was compromised through a known vulnerability in a payment gateway plugin. The attacker modified the checkout page to include a credit card skimmer (a technique called Magecart). Customer payment data was stolen for three weeks before a customer reported a fraudulent charge that was traced back to the site.

What You Should Do Now

If you have read this far, you understand the threat. Here is what to do about it:

1. Get a security assessment. You cannot fix what you do not know about. A professional assessment reveals your actual attack surface. Contact us for a website security audit.
2. Update everything. CMS, plugins, themes, PHP/Node.js version. If your agency cannot do this, find someone who can.
3. Implement security headers. CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy.
4. Protect your admin panel. IP restriction, two-factor authentication, non-default URLs, strong passwords.
5. Set up monitoring. File integrity monitoring, uptime monitoring, and Google Search Console alerts for security issues.
6. Have an incident response plan. Know who to call and what to do if your site is compromised.

Attackers follow a predictable pattern. If you understand that pattern, you can defend against it. The question is not whether your site will be scanned and tested. It already is. The question is whether it will hold up.