Sakura Internet Incident Puts 1.36 Million Accounts Under Review

Sakura Internet's investigation has expanded from confirmed unauthorized logins to 583 rental-server accounts into a separate sales-management system that holds subscriber, billing, and contract information. Its August 19 disclosure says 1,360,563 member accounts may be affected. The August 21 customer FAQ says that figure is the potentially affected population, not a confirmed count of leaked records, and that the company has not confirmed data being taken outside its systems. The company has confirmed malware on some servers and the possibility that customer data in the original hosting scope was viewed or obtained.

The potentially affected member fields include identifiers, names, organization details, addresses, phone numbers, email addresses, dates of birth, service and contract details, and billing amounts. Sakura says it does not store card data and that hashed password information for 30 accounts may be affected. The sales-management system is separate from service environments such as Sakura Cloud, while the original incident did reach some rental-server customer areas. Customers should follow individualized notices, rotate reused passwords and affected hosting credentials, inspect sites and mail activity, preserve evidence, and treat incident-themed messages as likely phishing lures.

Sakura Internet detected an anomaly in a company-managed server environment on August 9. Its August 17 notice says a third party moved through that managed environment into some Sakura Rental Server customer environments. The investigation confirmed unauthorized logins affecting 583 accounts, malware on some servers, and access to areas available to those customer accounts. The company said customer-stored information and user identifiers may have been viewed or obtained, while no customer reports of site alteration had been confirmed at that point.

After revoking credentials, blocking access, and continuing the forensic investigation, Sakura identified possible unauthorized access to a sales-management system before the August 9 detection. That system manages subscriber, billing, contract, and related customer information. The August 19 notice widened the potentially affected population to 1,360,563 member accounts and said some hashed password information may have been accessible.

The company is still investigating whether the sales-system access and rental-server compromise are connected. The 583 rental-server accounts are included within the 1,360,563-member population, so the figures must not be added together. The first number describes confirmed unauthorized logins in a service environment. The larger number describes records that may fall within the sales-system impact boundary. Keeping those definitions separate prevents a cautious disclosure from being rewritten as 1.36 million confirmed compromised hosting accounts.

Sakura's August 21 FAQ states that it cannot yet tell every customer whether an individual account is included. It says the 1,360,563 accounts are the member records in the system that could be affected, not records proven to have leaked. The company also says it has not confirmed external removal of the data and continues to determine what was viewed or obtained. Those are material limits on the current evidence.

No confirmed exfiltration is not the same as proof that no data left. An investigation may lack complete database audit logs, network telemetry, object-level access history, or an established transfer destination. Conversely, system access alone does not justify claiming that every record was copied. Incident reporting should use the company's exact confidence boundary: possible access to a defined data population, confirmed unauthorized activity in the smaller hosting scope, and unresolved acquisition or exfiltration in the wider sales-system scope.

Organizations using Sakura services should record what they know locally while the provider investigates. Preserve Sakura notices, account and contract identifiers, administrator and FTP logs, mail logs, deployment records, DNS changes, and timestamps for unusual activity. If a notification later narrows or expands the impact set, that evidence allows operators to reconstruct which credentials, sites, mailboxes, or customer communications were exposed during the relevant period.

The FAQ lists member ID, company and department names, address, name, phone number, email address, date of birth, gender, fax number, contracted service, contract period, and billed amount among the fields potentially in scope. Sakura says it does not retain credit-card information, so payment-card data is outside the stated boundary. That exclusion matters, but it does not make the listed identity and contract data harmless.

Service names, contract dates, billing amounts, and contact details can make support impersonation more convincing. A lure can cite a real product or account detail, claim that credentials must be verified after the incident, and direct the recipient to a fake login page. The original hosting incident also creates a separate concern: if a customer site or mail account was reached, attackers may be able to send convincing messages from infrastructure recipients already trust. Customers should validate incident communications through Sakura's official site and known support channels.

Sakura says it will contact customers who require individual action through their registered email address and official notices, and that it will not ask for passwords, authentication codes, or card details by email or phone. Organizations should brief support desks, finance teams, domain administrators, and hosted-site owners on those rules. Filter and investigate lookalike domains, unexpected password-reset messages, fake billing corrections, and requests to disclose a one-time code.

The customer FAQ says hashed password information for 30 accounts may be affected. It does not name the hashing algorithm, salt design, work factor, password strength, or whether the relevant values were actually obtained. A password hash is not a plaintext password, but an attacker who obtains a verifier can attempt guesses offline. The result depends heavily on the storage design and on whether the original password is predictable or reused.

NIST's current digital identity guidance says password verifiers should be salted and hashed with a suitable password-hashing scheme and a practical cost factor, and explains that offline attacks are not constrained by an online login rate limit. It also warns against password reuse because a credential recovered or captured at one service can be tried elsewhere. Users should not infer that the word hashed eliminates risk, nor should they infer that all 1.36 million password hashes were exposed. The disclosed hash scope is 30 accounts under investigation.

Sakura says immediate member-menu password changes are not a high-priority requirement because that login enforces a second factor, but it recommends precautionary changes and strongly recommends changing the same password on any other service. Rental-server customers are also advised to change server or FTP and mail-account passwords. Use unique generated passwords, verify the account's second-factor settings, keep the registered recovery email current, and revoke or replace credentials named in an individual notice.

Sakura says the sales-management system is separate from the environments that deliver services such as Sakura Cloud. The first notice also said no impact had been confirmed for Sakura VPS, Sakura Cloud, dedicated physical servers, or its high-performance physical service at that time. The University of Tokyo's WebPARK team separately told its organizations that the member-information scope did not include their WebPARK organization data based on information available on August 19.

These boundaries argue against claiming that every cloud workload, virtual server, or dedicated host was accessed. They do not clear the 583 rental-server accounts or remove the need for customer-specific checks. A shared provider can have separate control planes, billing systems, support identities, and service environments. Risk follows the actual identity and management connections between them, not the broad label cloud.

Rental-server customers who receive a notice should inspect for unfamiliar files, administrator accounts, website or application changes, logins, and sent mail, matching Sakura's guidance. Capture hashes and timestamps before removing suspicious content, review scheduled tasks and deployment keys, validate domain and DNS settings, and compare hosted code with a trusted source. Customers outside the notified hosting set should still watch official updates and their own telemetry without presenting themselves as confirmed victims.

Sakura has disclosed containment steps including revoking credentials used for unauthorized access, removing malware, strengthening monitoring, expanding impact review to the sales system, engaging external forensic specialists, reporting to relevant authorities, and notifying affected customers. The company has not publicly described the initial access method, the exact start and end of attacker access, the malware family, whether persistence existed beyond the removed samples, or which logs support its current exfiltration assessment.

A useful next disclosure would separate confirmed access from inferred possibility for each system, give the observed time window, explain the relationship between the two scopes, enumerate confirmed and possible fields, and state what evidence supports or limits the exfiltration conclusion. It should also identify whether credentials, hosted content, mail, domain controls, or customer communications were modified. These details can be shared without publishing an exploit recipe.

For customer organizations, the durable lesson is to treat provider identity, billing data, hosting credentials, website content, and mail as linked incident surfaces with different evidence. Keep provider contacts and asset ownership current, require unique credentials and independently held backups, export high-value logs, and rehearse how to validate a provider breach notice outside email. That preparation supports proportionate action while the provider's investigation is incomplete.