This is the second blog in our series looking at the ‘why’ behind the ‘what’ at Push. In this entry, we’re exploring the idea of shifting detection and response left in the face of modern identity attacks.
This is the second blog in our series looking at the ‘why’ behind the ‘what’ at Push. In this entry, we’re exploring the idea of shifting detection and response left in the face of modern identity attacks.
As an industry, we’ve been conditioned to think about threat detection and response as something that happens post-compromise. Best practice has formed around resources like the Cyber Kill Chain and the MITRE ATT&CK Framework which focus on detecting indicators of an attacker presence on your network, and their behaviors and actions as they move through it.
But with the shift to identity attacks, where attackers look to take over accounts on internet-facing apps and services, relying on an assumed compromise approach to detection is becoming less reliable. The most significant breaches of the last 12-18 months have been the result of identity attacks where an attacker has taken over an account, exfiltrated data… and that’s it.
This change means that the typical methods of post-compromise detection and response become much less viable. So, we’re going to talk a bit about what’s changed, why controls are failing, and what we’re doing here at Push to address the detection gaps.
The good old days
Over the previous decade the typical attack paths, and the controls that have formed around it, have become very familiar to SecOps teams.
Even with the more recent shift to enterprise cloud and hybrid networking, the broad offensive logic of “land and expand” remains. This has seen the typical view of a network-based attack path simply expand to add first enterprise cloud, and then Saas to the picture.
And while this sort of attack path is theoretically possible, what happens in reality looks quite different.
The new world
Instead of needing to progress through the network, moving laterally, elevating privileges, etc. modern account takeover tends to take a much more direct approach.
It’s a common misconception that SaaS compromise typically comes after the traditional attack chain (a myth largely promoted by old-school consultancy providers, MSSPs, and managed SOC providers). There’s no need for an attacker looking to take over a SaaS account to target the network first – and many organizations today simply no longer have a network in the conventional sense.
This isn’t to say that there aren’t examples of longer SaaS compromises involving lateral movement from SaaS to SaaS, or SaaS to cloud (we created a whole attack matrix demonstrating the art of the possible here). Equally, there are examples of very short and direct attacks in enterprise cloud environments leading to ransomware deployment (for example, Scattered Spider turning an initial account takeover in Okta into a full-scale VMware ESXi ransomware compromise).
But statistically, the average network or enterprise cloud attack involves much more complex lateral movement, privilege escalation, and defense evasion than the average SaaS attack path.
The Snowflake attack path is a useful case study here:
Attackers logged into the Snowflake tenant of ~165 organizations using stolen credentials to access user accounts via the web-based ‘SnowSight’ portal.
To take advantage of the many exposed accounts, the attacker created a utility performing account takeover and recon at-scale.
The attack finished with the attacker executing the same set of SQL commands across customer instances to stage and exfiltrate data.
And that’s it.
Since these attacks happen in-app, to be able to detect and intercept them you’d need deep app-level telemetry, and probably the ability to automate any containment and response activities. But unfortunately…
Detecting and responding after account takeover is really, really difficult
Limited log data
The first challenge is that in-app malicious activity is mostly indistinguishable from legitimate user behavior. Even mass data exfiltration might appear legitimate depending on what the app is used for!
To meaningfully detect malicious activity in-app, for starters you would need visibility of user behavior and actions. Unfortunately, you don’t have this.
We’ve previously discussed in detail why log sources like network (web proxy), IdP, and app logs fall short when it comes to identity attacks, but the TL;DR is that most applications provide extremely limited security logging (if they provide it at all).
When logs are available, you’re limited to the events that the third-party deems suitable to log. Out of the 100 most popular apps we see across our customers, and perhaps the few dozen or so that are security critical, only a small handful provide any useful logging. So extremely risky actions, like cloning a private GitHub repo, or downloading SharePoint files via ‘open in app’ or file syncing, don’t generate any logs at all.
Further, the lack of out-of-the-box connectors for many apps means that complex custom architectures are often required for ingestion.
So, even if logs are available and you’re able to ingest them into your SIEM, there’s no guarantee that the telemetry available will contribute to any meaningful detection of malicious activity.
Limited response capabilities
By some miracle, you’ve detected an account takeover. Now what?
The ability to respond to an attack is dictated by the controls that are available to the security team. Unfortunately:
Depending on the app and how it was adopted, there’s no guarantee that you have admin rights.
It’s not guaranteed that admins will have the required security features available to them, like forcing a logout on a session or disabling an account (you may not even know who the users and admins are within your organization, particularly if it was self-adopted by a specific team).
Response probably requires that you log into the app and perform these actions in the admin interface (rather than being something you can orchestrate via SIEM workflow or API).
So at the point that the SecOps team is engaged, the team needs to be able to respond by eradicating the attacker’s access and closing the vulnerabilities exploited to prevent re-entry. To do this, the team needs to be able to identify, for example:
How the attacker gained access to the account
What the attacker did using the compromised account
Whether any alternative access methods were established (e.g. backup emails, API keys, or OAuth integrations)
Where the attacker could have laterally moved to using the account (based on the integrations and permissions of the identity)
Other accounts the attacker could also access using the same credentials
Given the limited tools available and the probable lack of app-specific knowledge (you can’t be an expert in every app!), by the time you’ve managed to respond, the attacker has probably already sailed off into the sunset with all of the data they can lay their hands on.
Clearly, post-compromise detection and response isn’t really a viable option – you’re basically entering full response and recovery mode at this point.
Shifting detection left
If you can’t reasonably detect and respond to post-compromise activity, it makes detecting and blocking initial access much more important.
Again, it seems obvious, but it’s yet another notion that’s fallen under the radar – despite the trendiness of ‘shifting left’ in other areas like software development and vulnerability management. Partly because as we’ve discussed, post-compromise detection and response has been the norm for so long. But also because we’ve accepted the status quo of the (somewhat disappointing) preventative controls that are available.
First, let’s isolate the techniques and steps that attackers typically rely on for account takeover.
Methods of account takeover
To be able to hijack an account, an attacker needs to possess one of two things:
Authentication material e.g. a username and password, with a login portal URL.
Session material e.g. session cookies.
There are three main ways that an attacker can hijack an account by acquiring (or generating) these materials: Phishing, infostealers, and credential stuffing.
Phishing: Stealing valid authentication and session material from victims, including usernames, passwords, and session cookies (if AitM or BitM), for a specific site or app.
Infostealers: Stealing valid authentication and session material from the victim’s web browsers for all apps that the user has signed into, as well as desktop information from the device.
Credential stuffing: Using previously breached authentication or session material in data breach dumps, or taking advantage of weak or guessable passwords (as a result of password reuse).
Once this information has been acquired, the attack path follows a similar journey regardless of the initial attack technique, ending in the attacker initiating a session in their own browser.
Clearly, there are a number of steps here that involve user behaviors/actions that could in theory be detected with the right visibility:
The victim being sent and accessing a malicious link, or downloading a malicious file
The victim loading a malicious webpage
The victim interacting with a malicious webpage, such as entering their credentials
(If an infostealer attack) The victim executing malware on their device
Finally, the attacker must also access the stolen account from their own device/browser.
Existing controls are falling short
So, now we know what these attacks look like, how do you feasibly detect and block them?
The vast majority of identity attacks take place entirely over the internet. These attacks don’t involve traditional network and endpoint-based techniques, and therefore don’t run into many of your existing perimeter controls. Infostealer attacks are the exception in that they do involve an endpoint compromise (and therefore come up against EDR), but attackers are continually finding new bypass techniques, or are targeting unmanaged devices that are not protected by EDR.
This leaves us in the hands of TI-driven blocklists and SWG/email controls that identify and block malicious content. However, these controls are largely based on indicators like domain names, URLs, and IPs which are easy for attackers to change (and therefore bypass). Where pages and downloads are analyzed, attackers are routinely implementing obfuscation measures to defeat more advanced dynamic controls with a lot of success, or using techniques like HTML smuggling to bypass download scanning tools.
Detecting and responding to account takeover with Push
But, Push’s vantage point in the browser gives us a very different perspective. Because in the browser, you have much better visibility of the rendered web page (meaning it's much harder to disguise malicious content). You also aren’t restricted to email, and can intercept a user loading a malicious page whatever it’s source.
So, let’s compare the typical web-based controls that organizations rely on against what’s possible using Push’s browser-based solution. We’ll put EDR to one side here and focus on a typical phishing attack, since the majority of the attack path happens over the internet (and the attacker has to return to the internet to access the app/account anyway).
You can see here that attackers have established methods of routinely bypassing these controls. In contrast, with Push, there are layered detections against different stages of the attack path to account takeover, providing defense-in-depth should a layer be somehow bypassed.
In practice, this creates four strong lines of defense – all before an attacker can even take over an account.
1st line: Detecting when a login page that you access is cloned from a legitimate page.
2nd line: Detecting and blocking access to a page with a known phishing kit signature present on the page.
4th line: Detecting when an attacker resumes a stolen session in a browser without the Push extension running.
Each of these controls either detects and blocks the account takeover attempt outright, or provides a high-fidelity indicator that should trigger a priority investigation via your SecOps workflow.
Conclusion
Hopefully we’ve demonstrated shifting detection left isn’t just possible, but essential for defending against modern identity attacks and account takeover.
This is the second post in our design philosophy series, so if you want to read about how we’re building detections that are hard for attackers to bypass using the Pyramid of Pain, you can check it out here.
We look forward to sharing more about our design philosophy with you in the future!
