All vulnerabilities
CRITICALOpSeccurated

OPSEC-MARRIOTT-STARWOOD-2018

Hospitality · Marriott (Starwood)

Summary

In November 2018 Marriott disclosed that the Starwood guest-reservation database had been breached. The headline number moved as the investigation went on, from an initial 500 million down to a refined estimate of around 339 million guest records, including 5.25 million unencrypted passport numbers. The most striking detail was the dwell time: attackers had been inside the Starwood system since July 2014 and went undetected for more than four years, straight through Marriott's 2016 acquisition of Starwood. Marriott inherited the compromised infrastructure without knowing intruders were already in it, and only an internal security tool flagging an unusual database query in September 2018 finally surfaced the breach, which US government sources attributed to Chinese state-linked actors. It led to a $52 million multi-state settlement and a 20-year FTC security order. It is the lesson in mergers-and-acquisitions cyber due diligence, dwell-time detection, and protecting and encrypting sensitive records.

How it happened

The breach did not belong to Marriott at first; it belonged to Starwood, the hotel group (Sheraton, Westin, W) that Marriott would later buy. Attackers got into Starwood's guest-reservation system in July 2014, reportedly through a phishing-delivered remote-access trojan, and quietly settled in. When Marriott acquired Starwood in September 2016, it took on that reservation system, and the intruders sitting inside it, without detecting them. Cyber due diligence, if any was done, did not find a years-old active compromise.

So the attackers simply kept going, for more than four years total. They were finally caught on 8 September 2018, when a security tool Marriott had deployed flagged an unusual query against the Starwood database; forensics then turned up the remote-access trojan and the credential-stealing tool Mimikatz, which the attackers had used to harvest credentials and reach an administrator account that could query the guest database. The long, patient, espionage-flavoured profile pointed to a Chinese state group, an APT for whom a global hotel chain (a near-perfect source of who travelled where, and when, including government and military guests) is a high-value target, though Marriott never officially confirmed the attribution and no one was ever charged.

The damage

Around 339 million guest records were exposed. The data breaks down: roughly 8.6 million encrypted payment-card numbers (nearly all of them already expired), 20.3 million encrypted passport numbers, and 5.25 million passport numbers stored in plain text. On the encryption, Marriott was careful: it said it had found no evidence the attackers accessed the two components needed to decrypt the card data, though it could not entirely rule it out. Beyond the privacy harm, the travel histories of millions, including officials, carried clear intelligence value. The regulatory fallout was lasting, and it covered not one breach but three (an earlier Starwood intrusion, the famous four-year one, and a later breach on Marriott's own network running into 2020, together affecting more than 344 million customers): a $52 million settlement with 49 states and Washington DC in 2024, an FTC order finalised that December mandating a comprehensive security program for 20 years, and earlier, a UK fine the regulator first set at nearly £100 million before reducing to £18.4 million.

Why Marriott still matters

Marriott teaches two lessons that rarely get equal billing. The first is mergers-and-acquisitions security: when you buy a company you buy its breaches, so cyber due diligence belongs in the deal, and the acquired environment needs to be investigated and re-platformed, not run as an inherited black box. The point is sharpened by the fact that even while it was cleaning up Starwood, Marriott was breached again on its own network, the third incident in the regulators' case. The second lesson is dwell time: an intrusion that lasts four years is not bad luck, it is a detection failure, and it argues for behavioural monitoring and threat hunting rather than waiting for an alarm. Underneath both sits the basics, encrypt sensitive data, protect the keys separately so a database dump is not a plaintext dump, and minimise how much irreplaceable identity data (like passport numbers) you keep at all.

How to fix it

  • Isolate and rebuild the compromised database environment, and rotate all credentials and encryption keys it held.
  • Reconstruct the full multi-year intrusion timeline from whatever logs exist, and assume long-dwell persistence.
  • Validate that "encrypted" fields are actually protected and that their keys were not also stolen.
  • Notify affected guests and regulators, and stand up monitoring for the exposed identity and passport data.

How to avoid it

  • Make cybersecurity due diligence a gate in any acquisition; you inherit the target's intrusions along with its systems.
  • Invest in long-dwell detection and threat hunting; a breach undetected for years is a detection failure, not bad luck.
  • Encrypt sensitive data and store keys separately, so a database dump is not a plaintext dump.
  • Minimize and segment guest, payment, and passport data, and alert on unusual bulk access.
  • Retire and re-platform legacy acquired systems quickly rather than running them as inherited black boxes.

References

Related vulnerabilities

All OpSec →