The DreamHost response sequence: reset, revoke, verify, and monitor

DreamHost's public account gives defenders a useful incident-response sequence. The provider discovered unauthorized access to the File Manager server, removed it from service, reset potentially exposed passwords, ended active sessions, rebuilt the service, and opened an investigation. Customers need a matching sequence that focuses on their own accounts and evidence.

Response quality depends on order. Changing a password while an active session remains valid leaves access open. Revoking a session before checking forwarding rules can hide evidence. Rebuilding a file without preserving a copy of the suspicious original makes later analysis harder.

Phase one: stop onward access

Identify every user who may have entered FTP/SFTP credentials into files.dreamhost.com during the exposure window. Notify account owners through a private channel, reset affected credentials, and end active sessions where the provider supports it. Review delegated users because an owner-level reset does not necessarily remove a forgotten assistant or automation identity.

At the same time, preserve relevant evidence. Export mailbox-rule listings, authentication history, file metadata, deployment logs, and any provider notifications. Record when each action occurred. Do not overwrite a suspicious file before capturing its hash and a protected copy.

Phase two: verify the customer environment

Review website files against a known-good release or backup. Check for web shells, unexpected scheduled tasks, modified configuration, and new administrator users. Review mailbox forwarding, filters, recovery settings, application connections, and sessions. Then test the new credentials from the expected clients and confirm that old credentials fail.

The provider's scope estimate helps prioritize the work. DreamHost says the incident affected well under approximately 10% of hosted email and FTP/SFTP accounts. It does not identify which customer domains or business processes are in that group. Customer-side records must connect the provider notice to the account inventory.

Phase three: monitor the recovery

Watch for renewed access attempts, unfamiliar file changes, mailbox rules that reappear, and failed authentication bursts during the days after the reset. Review logs from the hosting account and any identity provider used by the organization. Give the service desk a clear escalation path for reports of password-reset emails, unusual invoices, or unexpected file changes.

ZoomEye can support the external part of the review. On November 15, 2026, domain="dreamhost.com" returned 122 all-scope public asset observations and domain="dreamhosters.com" returned 28. These are provider-controlled public surfaces observed at one time. They do not prove that a customer account was accessed or that a recovery action failed.

Phase four: close with evidence

Create an incident record with four sections: affected identities, containment actions, verification evidence, and residual risk. Mark each identity as verified, unresolved, or not applicable. For unresolved items, assign an owner and an expiration date. Do not close the incident merely because the provider's service is back online.

Measure time to credential reset, time to session revocation, percentage of accounts verified, and number of unexplained file or mailbox changes. These metrics show whether the response changed the risk, not just whether a task list was completed.

The final review should separate provider responsibility from customer responsibility. DreamHost controls its File Manager, account platform, and provider-side sessions. The customer controls its website content, mailbox use, integrations, and internal access policies. A clear handoff between those areas prevents both duplicate work and unexamined gaps.