Two Months of Exposure: A Field Guide to Breach Dwell Time

Scope

This guide helps you reduce the time between a vulnerability being exploited and your team discovering it, and outlines actions to take once you're aware. It uses the DreamHost File Manager breach as a case study. Attackers exploited a vulnerability in the software behind a web-based File Manager, capturing FTP/SFTP usernames and passwords from users who logged in between August 2026 and October 23, 2026, when the breach was discovered. Session information, including credentials for some webmail users, may also have been exposed.

The guide focuses on three areas: vulnerability management, third-party assessment, and breach communication. It aligns each with specific obligations under the GDPR and UK General Data Protection Regulation where applicable. This is not a full incident response plan.

Key Concepts and Definitions

Dwell time. The period between initial compromise and discovery. In this case, roughly two months. Every login during that window was a potential credential capture.

Credential-harvesting exposure. When an attacker accesses a service that handles authentication, exposure grows with each user session. Dwell time multiplies this risk.

Technical and Organisational Measures. The Article 32 GDPR standard for security requires measures "appropriate to the risk," including a process for regularly testing and evaluating effectiveness (Art. 32(1)(d)).

Breach Register. The internal record required by Article 33(5) GDPR. It documents facts, effects, and remedial actions for every breach, including those not notified.

Notification to Supervisory Authority. The Article 33 duty to report a personal data breach, where it is likely to result in a risk to individuals, without undue delay and where feasible within 72 hours of becoming aware.

Requirements Breakdown

Two points deserve emphasis. First, the 72-hour clock starts at awareness, not at compromise. A two-month dwell time doesn't breach Article 33 on its own, but it strongly indicates that detection controls were inadequate under Article 32. Second, a hosting provider typically acts as a processor for customer-hosted content and a controller for its own account data. Know which role applies to which data set before an incident, as it determines who notifies whom.

Implementation Guidance

1. Treat authentication-handling services as top-tier assets

A File Manager that proxies FTP/SFTP logins holds plaintext or recoverable credentials in memory or logs at the moment of use. Classify any service that touches credentials as Restricted Data infrastructure. That classification should drive patch priority, network isolation, and logging depth.

2. Set patch service levels by exposure, not CVSS alone

Internet-facing, credential-handling software should have the shortest remediation window you can manage. Define that window in policy, track exceptions, and report on them. If you can't patch, add compensating controls: a web application firewall rule, access restriction, or taking the service offline.

3. Instrument for credential-theft behavior

Dwell time shrinks when you detect behavior, not just known signatures. Alert on unexpected outbound connections from authentication servers, new processes on hosts that should be static, and bulk reads of credential stores or session data.

4. Commission third-party assessments on a schedule

External testers find what internal teams might miss. Scope them to include web-facing management tools, not just primary products. Retest after remediation, and feed findings into your Article 32(1)(d) evidence file.

5. Build the containment playbook before you need it

The response actions in this case are a useful template: block the attacker's access, patch the exploited flaw, terminate active sessions, and invalidate passwords. Pre-authorize your team to take all four actions without escalation delays. Add a fifth: force credential rotation on downstream systems where exposed credentials may be reused.

6. Communicate with specific, actionable guidance

Effective customer notices state what happened, what was and wasn't accessed, and what to do next. The DreamHost notification does several of these things well. It names the affected system, gives the exposure window, and states what it found no evidence of (control panel logins and billing details). It tells recipients to check site files for unauthorized changes, review webmail forwarding rules and filters, and change reused passwords. It also offers one year of credit monitoring and identity theft protection through Equifax, and urges recipients to consider a fraud alert or security freeze.

Notice what makes the forwarding-rule and file-change advice valuable: it addresses attacker persistence, not just password hygiene. Your notices should anticipate how an attacker would use the stolen access.

Common Pitfalls

• Assuming "no evidence" means "no access." State what you checked and how. Overclaiming forces a later correction.
• Resetting passwords without killing sessions. Invalidating credentials while leaving sessions live leaves the door open.
• Ignoring persistence mechanisms. Mail forwarding rules, modified site files, and added keys survive a password reset.
• Treating credit monitoring as the main remedy. Here the exposed data was credentials, not financial identifiers. Monitoring is a goodwill measure; credential rotation and persistence checks do the real work.
• Slow responses to press and customer questions. Unanswered inquiries about the number of affected accounts erode trust. If you can't give a figure yet, say so and give a date for the next update.
• Skipping the Breach Register. Record the incident even if you conclude notification isn't required, with your reasoning.

Quick Reference Table

The core lesson is simple. Exposure grows with dwell time, so your detection and patching speed set the ceiling on harm.