From 1,200 Daily Alerts to 31: How an E-Commerce Store Deployed XHack SOC and Caught a Credential Stuffing Campaign in Week One

Executive Summary

A direct to consumer e-commerce business with approximately 15,000 registered customers and a small engineering team had a growing security blind spot. Their Cloudflare dashboard was generating hundreds of WAF alerts daily. Their hosting provider's monitoring panel added another stream of system level warnings. Nobody had time to review either.

The store had been targeted by a credential stuffing campaign that had been running for nine days before XHack's SOC platform was deployed. The attack was slow, distributed across residential proxy IPs, and deliberately designed to stay below the thresholds that basic rate limiting would catch. It was burning through a leaked credential list against the store's login endpoint, and it had already compromised several customer accounts.

XHack deployed the SOC platform on a Tuesday afternoon. Three hours later the dashboard was live. On Thursday morning the attack chain engine flagged a pattern that no individual tool had surfaced: a coordinated sequence of low rate login failures from rotating IPs, followed by successful logins to accounts that had never logged in from those geographic regions, followed by shipping address changes and high value orders placed within minutes of the account takeover.

The campaign was contained within forty eight hours of detection. Compromised accounts were locked, fraudulent orders were cancelled before fulfilment, and the login endpoint was hardened with additional controls.

This case study documents what happened, how the detection worked, and what changed afterwards.

Client Background

The client runs an online store selling consumer electronics and accessories directly to customers. They operate on Shopify for the storefront with a custom Next.js frontend, backed by a Node.js API layer running on a managed Kubernetes cluster. Their product catalogue includes approximately 2,000 SKUs and they process between 400 and 600 orders per day during normal trading periods.

Their team consists of twelve people. Eight are engineers working on the platform and product features. Two handle operations and fulfilment. Two manage marketing and customer support. There is no dedicated security role.

The store sits behind Cloudflare with their Pro plan, which includes the WAF, bot management, and DDoS protection. Their hosting provider offers basic server monitoring with alerts for CPU, memory, and disk usage. The application layer generates logs that are shipped to a cloud logging service but are primarily used for debugging production issues, not security analysis.

This is a common setup for a business at this stage. The security tooling exists, it is generating data, and nobody is systematically reviewing it because there is no one whose primary job is to do so.

The Alert Fatigue Problem

When XHack connected to the client's Cloudflare account during onboarding, the security events dashboard showed 1,247 events from the previous twenty four hours.

The breakdown was roughly as follows.

Approximately 500 events were WAF rule triggers on legitimate traffic. The client's Next.js frontend generates internal API calls to paths like /_next/data/ and /_next/image/ that contain URL encoded parameters. Cloudflare's managed SQL injection and XSS rules were matching against these paths because the URL patterns superficially resemble injection payloads. Every page load by every visitor was generating multiple false positive WAF events.

Another 300 events came from bot management. Googlebot, Bingbot, and various SEO crawlers were being flagged alongside actual malicious scanners. The client had no way to distinguish between the two without manually checking each user agent string and cross referencing it against the request pattern.

The hosting provider's monitoring added approximately 200 system level alerts per day. Kubernetes pod restarts during normal scaling events, temporary spikes in database connection counts during peak hours, and certificate renewal processes were all generating warnings at the same priority level as genuine security indicators.

The remaining 200 or so alerts came from the application's own logging. Failed login attempts, expired JWT tokens from mobile app sessions, and payment gateway timeout retries were all flagged as security events by the basic alerting rules the team had set up when they first deployed the logging service.

The total was over 1,200 alerts per day. The engineering team had a Slack channel where these alerts were posted. The channel was muted.

Deployment

XHack's SOC platform was deployed on a Tuesday. The onboarding took three hours from the first configuration step to the first correlated alert appearing on the dashboard.

Log Source Integration

Two primary log sources were connected:

Cloudflare Security Events were integrated using the GraphQL API. The adapter pulls WAF events, bot scores, firewall rule matches, and managed challenge outcomes at five minute intervals. Each event is normalised into the SOC's standard schema: source IP, request path, HTTP method, response status, user agent, geolocation, and Cloudflare specific fields including bot score, threat score, and the rule ID that triggered.

Application Logs were connected via a webhook integration. The client's existing logging pipeline was already shipping structured JSON logs. A forwarding rule was added to send security relevant events to XHack's ingestion endpoint. These included authentication events (both successful and failed), account modification events, order placement events, and rate limit violations.

Both sources were producing normalised events in the SOC dashboard within ninety minutes.

Detection Rule Tuning

The noise reduction came from three layers of tuning applied to XHack's built in detection rules.

Framework path exclusions were the single biggest improvement. All web attack detection rules, including SQL injection, XSS, command injection, path traversal, and SSTI, were wrapped in AND condition groups that excluded requests to /_next/, /_nuxt/, and /static/ paths. A regex exclusion for static file extensions (JS, CSS, images, fonts, maps) was added alongside. This single change eliminated approximately 500 of the 1,200 daily Cloudflare alerts.

Monitoring and crawler exclusions were applied to the scanning detection rules. Known search engine bots and uptime monitoring services were excluded from the web scanner and rapid 404 detection rules using user agent pattern matching. This removed another 200 alerts per day.

Alert stacking handled the remainder. When the same detection rule fires for the same source IP within a six hour window, the SOC does not create a separate alert for each event. It groups them into a single alert with an expanding event count. A scanner probing the site 150 times from one IP produces one alert with 150 stacked events, not 150 separate alerts. Each stacked event is preserved for investigation. Nothing is lost. The noise is compressed, not discarded.

After these three layers of tuning, the daily alert count dropped from over 1,200 to approximately 31.

Those 31 alerts were real.

The Detection

On Thursday morning, two days after deployment, the SOC's attack chain detection engine flagged a sequence of events that crossed three distinct stages of the MITRE ATT&CK kill chain.

What the Attack Chain Engine Found

The engine runs every ten minutes. It looks for patterns where a single source generates events that map to multiple kill chain stages within a configurable time window. For this client, the window was set to seventy two hours.

The engine correlated the following events:

Stage 1: Initial Access (Credential Stuffing). Over the nine days preceding SOC deployment, the login endpoint had received a sustained low rate stream of authentication attempts. The attempts came from approximately 340 unique IP addresses, most of which resolved to residential proxy networks. Each IP sent between 3 and 8 login requests before rotating. The total volume was approximately 4,000 login attempts over nine days, an average of around 18 per hour, deliberately kept below any reasonable rate limit threshold.

The credential pairs being used were not random. They followed the pattern of a leaked credential database where email addresses matched real accounts on the platform. Approximately 2% of the attempts succeeded, consistent with the expected hit rate for a credential stuffing attack using a moderately fresh breach dump.

Stage 2: Account Takeover. Successful logins from the credential stuffing campaign showed a distinctive pattern. The compromised accounts logged in from IP addresses in geographic regions that had no historical association with those accounts. A customer in Manchester whose account had only ever been accessed from UK IP addresses was suddenly logging in from a residential proxy in Southeast Asia. Seven accounts showed this pattern.

Stage 3: Fraud Execution. Within minutes of the account takeover, the compromised accounts were used to change the shipping address to a new destination, add a high value item to the cart, and place an order using the stored payment method. Three fraudulent orders had already been placed and were in the fulfilment queue.

No individual tool flagged this chain. Cloudflare saw the login attempts but they were within normal rate limits. The application logs recorded successful logins and order placements as legitimate activity. It was only when the SOC engine correlated the failed login patterns, the anomalous geographic logins, and the rapid account modifications that the full attack became visible.

Investigation

The security team reviewed the attack chain on the SOC dashboard within hours of the alert. The stacked events view showed the full timeline: which IPs attempted login, which accounts were compromised, what changes were made to each account, and which orders were fraudulent.

The normalised data view for each event provided structured information. Source IP, geolocation, user agent, the specific endpoint hit, the HTTP status code, and the response time. The raw data was also available for anyone who needed to see the exact request and response payloads.

The attack had been running for nine days. The three fraudulent orders had been placed over the previous four days. Two were still in the warehouse awaiting shipment. One had already been dispatched.

Containment

The client's team executed containment within forty eight hours:

All seven compromised accounts were locked and their sessions invalidated. Password reset emails were sent to the account holders from the client's support team, along with a notification explaining what had happened and recommending they change passwords on any other services where they used the same credentials.

The three fraudulent orders were cancelled. The two that had not yet shipped were pulled from the fulfilment queue. The one that had been dispatched was flagged for interception with the carrier.

The 340 IP addresses associated with the credential stuffing campaign were blocked at the Cloudflare level. A new SOC detection rule was created specifically for low rate distributed login failures with geographic anomaly detection, tuned to the client's normal customer access patterns.

The login endpoint was hardened with additional controls. A progressive delay was added after failed attempts on the same account. A CAPTCHA challenge was introduced after three failed attempts from any IP within a one hour window. Account modification events following a login from a new geographic region were flagged for manual review before fulfilment.

Operational Impact

Before XHack SOC

The engineering team had no structured security review process. Cloudflare's dashboard was checked occasionally when someone remembered. The application log alerts were posted to a muted Slack channel. System monitoring alerts were only reviewed when they coincided with a production incident.

There was no correlation between log sources. There was no attack chain detection. There was no prioritisation of alerts by severity or kill chain stage. Mean time to detect was effectively infinite for any attack that did not cause a visible production outage.

After XHack SOC

Alert volume dropped from over 1,200 per day to approximately 31 grouped and deduplicated alerts. Each alert represented a genuine security event or a stacked group of related events from the same source and rule.

The engineering team introduced a daily fifteen minute security review. One person checks the SOC dashboard each morning, reviews any new alerts, and escalates anything that requires investigation. This replaced the previous approach of occasionally checking three separate tools and finding nothing actionable due to the volume.

SLA tracking was enabled for all incidents. Critical incidents were assigned a four hour response target. High severity incidents were assigned twenty four hours. The client has met these targets consistently since the second week.

The attack chain engine continues to run every ten minutes, correlating events across all connected log sources. Since the initial deployment, it has detected two additional patterns: a brief vulnerability scanning burst from a known threat actor IP range that was blocked within minutes, and an anomalous API usage pattern from a merchant integration that turned out to be a misconfigured webhook rather than a security incident.

Key Takeaways

Alert volume is not security coverage. Twelve hundred daily alerts from two separate tools produced less security value than thirty one correlated alerts from a single platform. The alerts were not wrong. They were just unmanageable. Volume without context is noise, and noise without review is the same as no monitoring at all.

Cross source correlation catches what individual tools miss. The credential stuffing campaign was invisible to Cloudflare because the login attempts were within normal rate limits. It was invisible to the application logs because successful logins from valid credentials look the same as legitimate access. The attack only became visible when login failures, geographic anomalies, and account modifications from the same credential chain were correlated across both sources and mapped to kill chain stages.

Low and slow attacks are specifically designed to defeat threshold based detection. Eighteen login attempts per hour across 340 rotating IPs will not trigger any reasonable rate limit. The attacker knew this. The only way to catch this pattern is to aggregate over time, correlate across multiple indicators, and look at the chain of behaviour rather than individual events.

Small teams benefit the most from automated correlation. A two person security function cannot review 1,200 alerts per day. They can review 31. The SOC platform did not add headcount to the client's security team. It made the existing team effective by compressing the noise and surfacing the signal.

Three hours is enough to deploy meaningful security monitoring. The client went from unreviewed alerts across two disconnected tools to a unified SOC platform with correlated detection, attack chain analysis, and a manageable daily review queue in a single afternoon. The barrier to deploying professional security monitoring is not time, complexity, or budget. It is the decision to start.

Further Reading

Article	What It Covers
SOC Dashboard Overview	Full walkthrough of XHack's SOC platform including event normalisation, detection rules, alert management, and incident response
Vulnerability Assessment Platform	How XHack's VA scanner integrates with the SOC for unified security monitoring
AI Probe: Adversarial AI Security Testing	Test your AI systems against OWASP LLM Top 10 attack categories
Platform Tour	See every feature of the XHack platform in action

About XHack

XHack is an offensive security company delivering penetration testing, red team engagements, AI security assessments, and managed security operations to organisations across e-commerce, finance, healthcare, and technology sectors.

The XHack SOC platform is available as a self service deployment for organisations that need professional security monitoring without the overhead of building and staffing a traditional security operations centre. The platform includes real time event ingestion, AI powered detection rules, automated attack chain correlation, alert stacking, and integrated incident management.

If your online store or web application is generating hundreds or thousands of security alerts that nobody is reviewing, the situation described in this case study will sound familiar.

Deploy XHack SOC  |  View Platform Tour  |  See Pricing