Approximately 10,000 unsuccessful login attempts. Ninety-four source IP addresses. Three days of sustained activity.

Yet the WordPress store remained online. No successful attacker login was observed, no administrator account was reported compromised, and the customer did not have to build or maintain a manual IP blocklist.

The website was using the Quttera WordPress Malware Scanner and Security Plugin, with Brute Force Protection, Login Protection, and Bot Protection enabled. As suspicious sources repeatedly failed to authenticate, the plugin responded automatically and progressively restricted their access.

This anonymized customer case study shows what a distributed WordPress brute-force campaign can look like—and why automated protection at the WordPress application level matters.

Brute-force and automated credential attacks remain persistent threats to WordPress websites. Instead of exploiting a sophisticated vulnerability, attackers can repeatedly test usernames and passwords against the login page. They may also reuse previously exposed credentials or distribute attempts across many systems to avoid simple per-IP controls.

For an e-commerce website, a compromised administrator account can expose far more than the WordPress dashboard. Depending on the account and website configuration, an attacker could potentially reach customer information, payment-related settings, plugins, themes, website files, or other business-critical controls.

Even an unsuccessful campaign can create operational costs by consuming server resources, filling logs with unwanted activity, triggering alerts, and forcing administrators to investigate or block sources manually.

The observed activity targeted the website’s WordPress login page for approximately three days. Plugin event records showed around 10,000 unsuccessful authentication attempts originating from 94 unique IP addresses.

The activity was not limited to one device repeatedly trying passwords. Multiple sources were active during the same periods, and some usernames and authentication patterns appeared across different IP addresses. This was consistent with a distributed, automated login attack.

Frequently targeted account names included predictable names such as:

`admin`
`support`

Some targeted account names corresponded to accounts used by the website, increasing the potential risk: once an attacker knows or correctly guesses a username, the password becomes the remaining authentication barrier.

To protect the customer, this case study does not identify the website, disclose account details, publish source IP addresses, or reveal sensitive authentication data.

Network attribution associated many of the source IP addresses with cloud and virtual-server infrastructure:

• 40 IP addresses associated with DigitalOcean networks—approximately 42.6% of the observed sources
• 9 associated with Hetzner networks—approximately 9.6%
• 7 associated with Microsoft Azure networks—approximately 7.4%
• 5 associated with Google Cloud networks—approximately 5.3%

Together, these four network groups represented approximately 65% of the observed source IP addresses. Other sources were associated with hosting networks, virtual private servers, and residential or business internet providers across several regions.

This attribution does not mean that any named provider conducted, authorized, or knowingly supported the activity. Attackers frequently misuse legitimate infrastructure, including compromised servers, stolen cloud accounts, temporary virtual machines, proxies, botnets, and poorly secured customer systems.

Cloud infrastructure is useful to attackers for the same reasons it is useful to legitimate businesses: it can be deployed quickly, offers reliable connectivity, and makes it possible to distribute activity across addresses and regions.

The Quttera plugin evaluated repeated failed authentication activity and automatically restricted suspicious sources. In the observed event records, restrictions were normally applied after approximately five to eight unsuccessful login attempts from a source.

The response escalated when suspicious behavior continued:

• An initial restriction of approximately 15 minutes
• Longer restrictions following additional authentication failures
• Escalation for repeat offenders
• Restrictions of up to 24 hours after a source was classified as attacking
• Security events and alerts for administrator visibility

This progressive approach is important. A legitimate user can occasionally enter an incorrect password, so treating every single failure as an attack could lock out real administrators or customers. Progressive controls allow ordinary mistakes while responding to patterns associated with automated abuse.

As activity appeared from additional IP addresses, the same protections were applied to each source based on its behavior. The administrator did not need to review thousands of requests or continually update a manual blocklist.

The observed campaign did not achieve its apparent objective.

During the three-day period:

• No successful attacker login was observed
• No WordPress administrator account was reported compromised
• No evidence of customer-data exposure was identified in connection with the activity
• No website downtime was reported
• No material performance degradation was reported
• No disruption to legitimate users was reported
• No manual blocking was required from the website administrator

After approximately three days, the observed malicious login activity ceased.

From the customer’s perspective, the protection worked quietly in the background while the store continued serving visitors. That is an important measure of successful website security: stopping malicious activity without turning protection itself into an operational burden.

The free Quttera WordPress Malware Scanner and Security Plugin provides security controls directly inside WordPress, including:

• Brute-force protection
• Login monitoring and protection
• Suspicious bot protection
• External and internal malware scanning
• Blacklist monitoring
• Security alerts and event visibility

After installation, open the plugin settings and confirm that the protection features appropriate for your website are enabled. Installing a security plugin without activating its relevant controls can create a false sense of protection.

The WordPress plugin is designed to provide accessible protection and security visibility directly inside individual WordPress websites. Agencies and organizations that need centralized monitoring across multiple websites, continuous external and server-side malware monitoring, reputation monitoring, incident response, cleanup, or managed protection can extend their coverage with Quttera ThreatSign.

Explore ThreatSign website protection → Plans & Prices

This anonymized case study is based on Quttera plugin security-event records from the observed three-day period, associated network-attribution data, and customer confirmation of the operational outcome.

Counts are approximate and describe activity visible to the deployed controls. A unique IP address does not necessarily represent a unique person or device. Network ownership and location data can change, and provider association does not establish provider involvement. “No compromise observed” describes the evidence available for the monitored period and should not be interpreted as a guarantee that no unrelated security event occurred outside the observed systems or timeframe.