Account takeover led to sensitive information leakage at Marriott. Let's see what we can learn from this breach.

Marriott seems to be constantly on the radar of cybercriminals. This shouldn’t come as a surprise – all hotels collect various personally identifiable information (PII) due to the nature of their business, which makes them juicy targets. In the first breach in 2018, cybercriminals – among others – stole and published 8.6 million credit card numbers (in “encrypted” form, though), the majority of which luckily have already expired by the time of the breach (but why did they still store them in the first place?). Following this, the sensitive data of some 5.2 million guests participating in their Bonvoy loyalty program has leaked in 2020, via account takeover at one of their franchise partners.

In this latter breach, various type of sensitive information leaked: guests’ personal and contact details (such as gender or birthday, postal and email addresses, phone numbers), preferences (such as room preferences or languages), Marriott and airline loyalty information. Luckily, no account info (like passwords or PINs), payment card details, SSN, passport, ID or driver’s license numbers were leaked. But still, the revealed information was perfectly enough for someone to start a phishing campaign and do nasty things based on that.

Based on the information provided, the bad guys somehow learnt the login details of two employees at a franchised hotel. By logging in to the system with these credentials via the application that provides services to guests, they were able to do account takeover, and get access to a massive amount of information stored there for roughly a month, before Marriott detected the breach. So, once again, we have seen employees’ accounts being compromised (or was it directly an insider attack?), exacerbated by insufficient authentication and authorization procedures.

There is no information about how they obtained the two credentials in question. It may have been a result of phishing, or possible credential stuffing. In the end, such attacks are always a kind of insider threat. A Forrester survey has shown that 53% of data breaches were results of insider threats. These kinds of attacks are either caused by an insider who is directly malicious, or, just a careless employee whose credentials get stolen. And the biggest challenge, as always, is to detect such issues in a timely manner. Let’s focus on this aspect first.

If hacking is the poison, mitigation is the antidote

But the first step in solving any problem is recognizing that there is one. The earlier the better.

This specific breach did not happen by installing a malware or spreading a virus; that could have been caught by a good anti-virus or intrusion detection system. It happened via account takeover, and unauthorized use of the two perfectly valid accounts. But the two (fake) users started to download a huge amount of data via those accounts! This behavior was obviously unusual and outside of the system’s normal operation, so a good anomaly detection algorithm may have helped by dropping a warning in timely manner – definitely much earlier than the time it took them to download those 5.2 million records. But anomaly detection was obviously not in place or was configured inappropriately – which is especially surprising, as this was not the first time Marriot had been hacked.

Thus, it took Marriot approximately a month to realize they were under attack; this is obviously bad. But, as always, you can look at the glass being half empty, or half full. In the first incident from 2018, it took them much more time to notice the incursion, and they’ve lost around half a billion records by that point; this time, it was “only” 5.2 million. Not great, not terrible – right? Well, it definitely could have been better: with a quick calculation, we can deduce that to access 5.2 million records in approximately a month and a half time, the attackers should have been accessing them – on average – at a rate of around 5000 records per hour. This could and should have raised a red flag after the first hour of such an activity, not just after a month or so.

But of course, detecting such anomalies when an attacker is using a genuine account is not easy in general. First, you need to understand “business as usual” by observing and learning the normal behavior of your users. Once you know that, you can detect anything that is outside of that pattern and can potentially detect any breaches in timely manner. The sooner, the better.

As a side note, however, the Covid-19 pandemic made detection of such issues somewhat more difficult. Many usage patterns have changed; not only because people started working remotely, sometimes from a distant physical location, but also due to the fact that they worked on a slightly different schedule than before. This breach, however, took place before the pandemic, so blaming Covid-19 would be a bad excuse in this particular case.

From account takeover to phishing to account takeover

What can attackers do with all the personal data gathered via an account takeover – like that of the two employees of a Marriott franchise? Besides the obvious privacy aspects of leaking sensitive information, they can use it to do phishing, and get even more sensitive information. Both more information, and more sensitive information.

Attackers can target the victims with email campaigns, sending out – for instance – security warnings in the name of the victim company (Marriott in our case) that seems to be genuine, as they contain various pieces of information that refers to the victim (the target of phishing) correctly. Statistics say that more than 80 percent of phishing impersonates companies and brands. With such an email, attackers can potentially collect credentials from some naïve users, taking over their accounts, and do further spoofing by acting in their name.

After the initial breach is done, the same attackers that acquired the two initial credentials don’t even need to be involved with the rest of the job. The stolen database of personal records will get to the dark web, allowing anyone to do further account takeovers. This is low hanging fruit: it’s obviously much easier to just abuse an already broken account than to hack the system by exploiting hard-to-find vulnerabilities. Username and password pairs will be used to accomplish credential stuffing, which basically means using automated scripts and similar tools to take over the victims’ other accounts on different websites. If any of these credential stuffing attempts are successful (meaning that some of the victims reused their compromised credentials on a different site) , the attackers can log in to those accounts, and take full control of them as well – even change the passwords if they want to.

And that closes the nasty account takeover cycle.

Overtaking the takeover

What can we do to protect against account takeover leading to phishing? It’s all about doing some basic security things: authentication, authorization as well as activity monitoring and intrusion prevention. And doing them right.

These days two-factor authentication is standard – especially for sensitive accounts. Just using the good old username-and-password authentication is not enough anymore – not to talk about all the recent changes in password policy trends. Two-factor (or even multi-factor) authentication hardens the process and makes spoofing harder, as in that scenario it is not enough for the attackers to steal your credentials – they also have to physically steal your device that receives or generates the PIN codes you also have to provide or use when logging in. Any such physical world-based protection always make system more resilient to cyberattacks.

Another additional factor that is being widely used these days is location – geo-location or just cyber-location (e.g. an IP address or just a range of it). That is a factor that cannot be used on its own (unlike username/password or a secret key) but can be used as part of the overall authentication process to detect unusual activities. If you usually pop up in Berlin, and then all of a sudden you try to log in from Kishinev, the system may raise the security level, and ask you for additional proof that it is still you. Which is a good thing against account takeover in general, but of course using location as an add-on factor for hotel apps and the travel industry in general is not as good idea in practice, for obvious reasons.

As for phishing itself, there are various email security protocols through which a system can check and validate if the email is really originating from the account that is claimed in the sender field of it. It’s about authenticity after all, and is more on the ops side of security.

But even in the previous examples we basically tackled the problem by behavior analysis: detecting events that are outside of the business-as-usual. The importance of this is also highlighted in OWASP Top Ten: A10 Insufficient Logging and Monitoring is exactly about this. Prepare for even the unknown vulnerabilities and detect account takeover, intrusion attempts or just reconnaissance – when hackers are exploring the possibilities for potential attacks – in a timely manner.

Additional layers of protection include adopting the principle of least privilege on all layers of the system. This means that everyone should have the least possible privileges that are just enough for them to accomplish their job, and nothing else. This can remarkably limit the consequences of a successful attack. Remember: risk is always the combination of the likelihood (probability that the threat will occur) and the damage (how much it will hurt when it does occur).

But we can also include all best practices we discuss in our courses. Proper authentication and password management (hashing, salting and peppering, applying password policies, using the right adaptive hash algorithms, etc.), proper session handling (session termination, cookie protection, etc.), fail safe default values and default behavior, proper authorization (preventing confused deputy situations, keeping horizontal authentication in mind, etc.), and the extremely important principle of psychological acceptability (not forgetting that your users are human beings). Just to mention a few. As always, it is all about educating employees – both as users of computer systems, as well as their developers.