Use Case: Third-Party App Attacks

Let's take a look at a relatively new and more advanced type of attack. This is going to be something referred to as consent phishing.

So if we dive into this email, let's take a look at the details of this. We have a sender sending an email with the friendly name of Portal. It looks like they've used a zero instead of an o in Support.IT, but we see it's coming from this Albert at some random domain. It's very likely a compromised domain being leveraged here so that it is going to pass all of your sender authentication methods.

This is coming into a user within our organization. The email's very simple. It's saying, "Hi, Your account password will expire today. To continue using the same password, process below accordingly." There's a simple link for you to click on here. We can even show you exactly what this would look like if they went out to this.

And in this case, this is going to redirect a couple of times, but it's going to end up going out to this legitimate Microsoft application permissions site to grant these permissions for a third-party application tying into Microsoft. And you can see this is going to actually give read/write access to all mail, as well as a few other settings here. So this is a very, very advanced attack going out to a legitimate Microsoft service to actually do this.

The threat actor's goal here, of course, is to get these permissions granted so that they can leverage this account even without having credential access to it. They can use this third-party app now to send and receive emails from this user's account and potentially more accounts depending on the permissions. We can see that the link within this email is going out to this app.hive[.]co, which is actually a legitimate service that can be used to redirect or for quite a few other purposes.

And again, it eventually does redirect. So this is going to pass those traditional threat intelligence methods. There's nothing from a sandboxing perspective or browser isolation that would detect this. This is very, very difficult to detect from that traditional sender reputation, content, and threat intelligence perspective.

So how is Abnormal uniquely detecting this attack?

Well, there's a lot more than we're showing here taking place, but we can see looking at this. So, looking at the unusual sender, we see that the sender's name resembles an administrator account, but we've never seen emails coming from the email address that we see here. And looking at the links, we did go ahead and identify that there were some email addresses in the URL's path. It's very, very common that we see with these credential phishing attacks, where it's going to auto-input the user's email address and of course, track it leveraging that information.

Looking at the attack analysis, we see, again, the name impersonation and the automated systems, and this is eventually being identified as a credential phishing attack. When we do identify attacks of this type, we are going to automatically remediate them so users would never have access to them.