Most website compromises follow a predictable timeline. Reconnaissance to exploitation takes under 30 minutes for automated tools. Persistence is established within hours. Data exfiltration begins before most site owners have any idea something is wrong. The average time to detect a website breach is 49 days. Understanding each phase gives you a clear map of where defenses matter most — and why prevention is dramatically cheaper than response.

Phase 1: Reconnaissance (Minutes)

Attackers rarely target your site specifically at first. Automated scanners — Shodan, Censys, custom mass-scanning tools — continuously index the internet, cataloging software versions, open ports, response headers, and misconfigurations. When your site exposes a vulnerable WordPress version in its generator meta tag, an outdated plugin version in a response header, or an accessible admin panel at a predictable path, it enters attacker databases automatically.

A targeted attacker will also read your robots.txt file to map hidden paths, enumerate subdomains using tools like Amass or Subfinder, spider your site for forms and API endpoints, and check your response headers for server and framework version information. This phase produces a complete map of your attack surface — before a single malicious request is sent.

Phase 2: Initial Exploitation (Minutes to Hours)

With reconnaissance complete, the attacker selects the most accessible entry point. The most common initial access vectors in real-world website compromises:

Automated exploitation frameworks test dozens of vulnerability classes sequentially. Manual attackers focus on the fastest path with the highest privilege gain — typically a single SQL injection or a known plugin CVE with a public proof-of-concept exploit.

Phase 3: Establishing Persistence (Hours)

The first priority after initial access is ensuring continued access, even if the original vulnerability is patched. Attackers plant backdoors designed to survive remediation attempts.

Webshells are the most common persistence mechanism: small PHP, ASP, or JSP files placed in the document root (often in upload directories like wp-content/uploads/image.php) that accept and execute arbitrary commands sent via HTTP. A typical webshell is 5–15 lines of code and gives the attacker complete control over the server process. They are specifically named to blend in with legitimate files and placed among hundreds of real files to avoid cursory inspection.

Attackers may also create rogue admin accounts in the CMS, add SSH keys to authorized_keys files, install malicious cron jobs that periodically re-establish access, or modify existing PHP files to include a backdoor alongside legitimate code — making detection harder because the file appears to serve a legitimate purpose.

Phase 4: Privilege Escalation and Lateral Movement (Hours to Days)

If the web server process runs with limited permissions (as it should), attackers look for escalation paths. Common vectors: local privilege escalation vulnerabilities in the operating system, SUID binaries, cron jobs running as root, or database credentials in configuration files that allow direct database access with higher privileges.

Database access often yields admin credentials stored in plaintext or weakly hashed (MD5, unsalted SHA-1) in the users table — which are then cracked and used to access other systems. On shared hosting, lateral movement means compromising other sites on the same server. On cloud infrastructure, it means querying instance metadata services for IAM credentials and pivoting to S3 buckets, RDS databases, or other cloud resources the web application role has access to.

Phase 5: Exfiltration (Days)

What attackers take depends on what your site holds. Common exfiltration targets:

Exfiltration is often slow and low-volume to avoid detection — a few hundred records per day rather than a single massive export that might trigger anomaly alerts in database monitoring systems.

Phase 6: Monetization

Attackers monetize access in multiple ways simultaneously, often selling access to other parties so multiple unrelated groups use your server concurrently. Common monetization methods:

Phase 7: Discovery (Weeks to Months Later)

The average time to detect a website breach is 49 days. Most site owners discover the compromise through external signals rather than internal detection: a user reports unusual behavior, Google Search Console shows a manual action warning, the site is blacklisted by antivirus databases causing browsers to display red warning pages, or the hosting provider suspends the account for abuse (spam sending, malware distribution).

By the time discovery happens, backdoors have been in place for days or weeks, data has already been exfiltrated, and multiple persistence mechanisms may exist. Simply patching the original vulnerability is not enough for full remediation.

Remediation: What Recovery Actually Requires

A full compromise response involves more than patching the entry point. The complete steps:

  1. Take the site offline or into maintenance mode to stop ongoing damage
  2. Forensic review of all files modified since the estimated compromise date using file integrity tools or find with the -newer flag
  3. Rotate all credentials: database passwords, admin accounts, API keys, SSH keys, session secrets
  4. Rebuild from a clean, pre-compromise backup — not a backup from after the compromise date
  5. Patch the original vulnerability before bringing the site back online
  6. Scan the restored site for remaining backdoors and malicious file modifications
  7. Assess breach notification obligations: GDPR requires notifying the supervisory authority within 72 hours of becoming aware of a breach affecting EU residents

How Shieldome Helps

Shieldome is built for the prevention phase — identifying and closing entry points before an attack begins. A Shieldome scan checks for the most common initial access vectors exploited in real-world attacks:

Sites that score above 80 on Shieldome's Risk Score have eliminated the vulnerabilities present in the vast majority of real-world website attacks. After a breach, Shieldome can be used to audit the restored site's security posture and confirm that the known entry points are closed before returning to production.

Frequently Asked Questions

How fast can an attacker compromise a vulnerable website?

Automated exploitation tools can identify and exploit known vulnerabilities in minutes. A WordPress site running a plugin with a known critical CVE may be compromised within hours of the CVE's public disclosure, as automated scanners probe all detectable WordPress installations for the new vulnerability. Credential stuffing attacks run continuously, so a reused password appearing in a new breach dump can result in compromise within hours of that dump being sold or published.

How do attackers find websites to target?

Most attacks are opportunistic rather than targeted. Shodan and Censys index hundreds of millions of internet-connected hosts, cataloging their software versions and open services. Specific vulnerabilities — a critical plugin CVE, a newly disclosed SQL injection — trigger immediate mass scanning of all detectable installations within hours of public disclosure. Your site can enter an attacker's target list without any deliberate interest in your organization specifically.

Can I detect a compromise by reviewing my server logs?

Log review is useful but insufficient as a primary detection method. Sophisticated attackers delete or modify access logs. File integrity monitoring — comparing current file hashes against a known-good baseline — is more reliable for detecting webshell installation. Tools like AIDE or cloud-native file integrity services provide this capability. Correlating web server logs, database query logs, and system logs across sources provides the most complete picture.

What is a webshell and how do I find one?

A webshell is a malicious script placed on a server that executes commands sent via HTTP requests. Detection methods include: file integrity monitoring against a known-good baseline, content scanning for known webshell code patterns, reviewing recently modified files (especially in upload directories), and checking for PHP files in directories that should contain only images or static assets. After a compromise, assume webshells may exist in any directory writable by the web server process.

Is restoring from backup enough to fully recover?

No. Restoring from backup removes compromised files but does not address: the original vulnerability that allowed the compromise, any backdoors planted after the backup point, credentials that were stolen and remain valid, or data that was already exfiltrated. Full recovery requires patching the vulnerability, rotating all credentials, scanning for backdoors, and running a post-remediation security scan to verify the known entry points are closed.

Do I have to notify users if my site is breached?

Under GDPR, if personal data of EU residents is compromised, you must notify the relevant supervisory authority within 72 hours of becoming aware of the breach, and notify affected individuals if the breach is likely to result in a high risk to their rights and freedoms. US breach notification requirements vary by state and sector. The specific obligations depend on your jurisdiction, the type of data involved, and the scope of the breach — consult legal counsel for your specific situation.

How often should I scan for vulnerabilities to catch issues before attackers do?

At minimum, scan after every significant deployment or dependency update — new code introduces new attack surface, and updated components can introduce regressions. For production sites that handle user data, a weekly automated scan provides continuous visibility into your security posture. The cost of a scan is negligible compared to the cost of a breach: downtime, forensics, remediation, breach notification, and reputational damage.

Prevention costs a fraction of recovery. Run a free Shieldome scan to identify the vulnerabilities most commonly exploited in real-world attacks — before attackers find them.