On 15th Sep 2022, the official Uber communications channel confirmed that it has experienced a cybersecurity breach and is actively investigating the matter. According to the initial report, the attacker succeeded via social engineering techniques to gain access to Uber’s network and then find a powershell script with credentials to several SaaS applications. Using these admin credentials, they were able to log into applications and potentially cause severe damage. Making it even worse, the attack was not detected by Uber’s ATO detection system, nor any other detection system used by Uber.
This breach is yet another reminder of the need for better credential management procedures and authentication mechanisms. It also spotlights the need for better detection solutions that compensate for authentication limitations and detect successful bypasses of these mechanisms (what Gartner has defined as ITDR: Identity Threat Detection and Response).
In addition, it demonstrates the failure of UEBA techniques (which one can presume are used by Uber) to detect such authentication bypasses by an attacker. The reason for UEBA’s failure is that good attackers are able to stay below the limits generated by statistical quantities. This emphasizes the main limitation of UEBA to detect such ATO attacks, which is that the statistical quantities do not truly characterize user/entity behavior. So the question is: how should Uber have detected impersonation in its business applications?
ITDR-based user journey analytics
We assume that the attacker’s sequence of activities is not similar to a typical sequence of activities by a normal user and even a normal admin. Thus, if Uber’s detection solution would have learned the typical (normal) sequence of activities performed by Uber employees and administrators, and compared each sequence of activities performed in Uber’s infrastructure as well as in the SaaS applications used by Uber to the learned typical sequences (and YES, there are many typical sequences), the attacker’s sequence of activities would have been flagged as anomalous and suspicious.
We call such analysis “User Journey Analytics,” and it is based on reading the application and infrastructure log records and generating user journeys, which are sequences of activities performed by users (in this case Uber employees). Such a detection solution creates ‘normative’ user journey profiles with these journeys, where each such journey profile represents a typical working profile of Uber employees. Once created, these normative working profiles are used to detect anomalous journeys which may indicate suspicious sequence of activities. Such a detection solution must of course continuously learn new working profiles and refine the learned ones to accurately detect anomalous journeys.
To better understand User Journey Analytics, let’s imagine a bank with many rooms, including a vault with cash, gold, jewelry, and documents. The bank has a main entrance, and the vault has its door, which people go through to deposit or withdraw valuables. Customers walk through the main bank entrance, visit various rooms, and leave the bank.
Analyzing and learning the paths people take when they enter the bank, through their journey in multiple rooms and to the vault, helps us understand typical user journeys. We can then find potential malicious journeys by comparing each visitor’s journey to their learned user journeys. Malicious users and imposters will use a different journey. For example, they could spend more time in the bank because they don’t know where they’re going. Or they might quickly go in and out as fast as possible to avoid raising suspicion.
Analysis of these user journeys accurately detects impostors, as it is tough to imitate a user’s normal journey. It will also accurately detect insiders looking to misuse or abuse an application and deviating from their normal user journey profiles. In the Uber breach, User Journey Analytics could have detected that the imposter’s (the hacker) journey was not similar to normal employee typical journeys. Such an abnormal journey would have alerted Uber’s security team way before the attacker announced their hack on the company’s Slack channel.
In addition, we assume that Uber’s detection systems are currently focused on the infrastructure layer. However, after the attacker succeeded to achieve admin credentials to Uber’s SaaS services, they were mainly active in these SaaS applications, jeopardizing the plethora of proprietary information in them. Thus, it is imperative to monitor business application usage in addition to monitoring the infrastructure. User Journey Analytics can be applied to read any SaaS application audit logs, generate user journeys from these log records (i.e. sequences of activities in SaaS applications), and learn normal working profiles of Uber employees in these SaaS applications automatically via unsupervised machine learning. Uber could have used these learned normative working profiles from the typical user journeys to quickly and accurately detect the impersonation breach.
