Skip Navigation
Get a Demo
 

Midyear trends

Insights from the first half of 2025, including a 5x increase in identity detections and new phishing investigations

Suspicious cloud logins blur the line between threats and risks

We were shocked to see an almost 500 percent increase in detections associated with T1078.004: Cloud Accounts in the first six months of 2025 compared to the entirety of 2024. While the data doesn’t lie, it does tell a nuanced story when you take a closer look, one that’s not simply about adversaries increasingly targeting identities. So what’s going on?

Cloud Accounts (T1078.004) detections

Identities and valid accounts

You might reasonably question how identities are driving an increase in detections for valid cloud accounts. It’s befuddling at face value but makes a lot of sense when you unpack what a typical identity detection looks like.

Identity detections usually consist of someone logging into a cloud-hosted system like Azure or Microsoft 365 through an identity and access management (IAM) system or a third-party identity provider (IDP) like Okta or Duo. Since the login technically pertains to a cloud account—and given the limitations of MITRE ATT&CK and ATT&CK mapping—T1078.004 is our best option for mapping these detections.

Identity detections and T1078.004 Valid Accounts: Cloud Accounts are inherently linked.

Identities and endpoints: Risks vs. threats

The reason we’re seeing such a dramatic increase in detections for suspicious login attempts to valid cloud accounts is nuanced as well. And that’s because identity and cloud detection is fundamentally different from traditional detection on endpoints, which will be a theme throughout this report.

On a workstation outfitted with an endpoint detection and response (EDR) sensor, you’re able to gather an enormous amount of context to investigate the veracity of a potential threat. You can see what happened before the threat occurred, you can see where the threat came from, and you can see what happened after the machine was compromised.

Identity detections are often more of a snapshot because logins occur at a single point in time. A legitimate user or an adversary either satisfies the login requirements—e.g., they enter a user name and password and satisfy the multi-factor authentication criteria—or they don’t. You likely don’t know what happened before the login and there may be visibility, logging, and correlation limitations that complicate the process of figuring out what happened afterward. Doing so requires deep visibility across potentially disparate systems and the ability to accurately associate and analyze logs from these disparate systems—and all this takes time.

Perhaps more importantly, waiting to see what an adversary accessed or what actions they took after compromising an identity is risky—especially in comparison to the less risky alternative of detecting and acting on the login itself. And that’s the key: in the identity domain, we’re much more concerned with diminishing risk. Upon compromising an identity, an adversary might go into your cloud infrastructure, your email accounts, or any variety of SaaS applications. You can spin your wheels investigating or you can act quickly to diminish the risk.

Suspicious logins

To that point, suspicious logins are the main driving force behind the massive increase we’re seeing in detections associated with T1078.004: Cloud Accounts. More specifically, we’ve expanded our identity detection coverage by leveraging agentic AI to examine logs from identity providers on a per-user basis to build user baseline reports—as demonstrated by the notable increases in May and June in particular. When a login deviates from the norm for a given user—e.g., the user logs in from an unusual device—an event is generated and investigated by a mix of humans, AI, and machine learning.

Some of this increase is being driven by new methods for detecting logins emanating from unusual IP spaces, locations, or suspicious virtual private networks (VPNs) in particular. We know that adversaries use VPNs to cloak their actual geolocation (because a login from a suspicious and unusual geolocation would be conspicuous and easy to detect) and we know that users probably shouldn’t be running consumer VPNs on company-owned computers, but we also know that people are using VPNs on their personal devices, where they also login to corporate accounts.

As such, these detections fall into a few different categories:

  • overtly malicious account compromises conducted by adversaries leveraging VPNs to cloak their geolocation or IP space
  • suspicious or unwanted logins where legitimate employees are violating policy by running unsanctioned VPNs on company assets
  • probably benign logins where people are accessing corporate accounts while knowingly or unknowingly using a VPN on a personal device

Differentiating between these three categories is difficult at scale, and some of these logins are obviously suspect while others are kind of ambiguous. However, suspicious logins certainly represent a risk to organizations, and you have to make a choice: either detect these kinds of risky logins and accept that you’re going to catch some benign ones or ignore them altogether and expose yourself to increased risk.

The importance of risk detection

The principle of risk detection is crucial across identities (and in the cloud as well, which we’ll examine in the Techniques section of this report). By the time you’re aware of a potential threat on an endpoint, there are thousands of sequential signals to investigate as an adversary pursues their objectives.

When we detect a threat on an endpoint, we know what happened before, during, and after the threat, and we’re pretty confident it’s malicious or suspicious (i.e., the investigation is largely done). By contrast, detecting a compromised identity is contingent on the characteristics of a sketchy login that’s already succeeded (or failed) and may represent a potential risk to your organization. You can capture user behaviors after the login that occurred on systems with sufficient logging and monitoring, but detecting the risky login and flagging the associated identity is often a starting point for an investigation that may take place on disparate other systems.

What we’ve learned from phishing investigations

Here are some interesting findings from our time spent investigating and confirming user-reported phishing emails. We highlight a few novel phishing attacks we’ve investigated and offer some high-level observations about phishing in general.

Phishing by the numbers

We investigated tens of thousands of user-reported phishing emails in the first half of 2025. In all, we confirmed that 16 percent of those emails were actual phishing emails. This underscores two points:

  1. Users are in fact reporting lots of phishing emails (great!)
  2. Benign emails often look an awful lot like phishing emails (not so great)

Of the confirmed phishing emails:

Interesting phishing attempts

Here are a few novel phishing campaigns we investigated this year.

Google Translate to hide malicious URLs
Adversaries used Google’s website translation service as a method to bypass email security defenses by embedding a malicious link within a Google-translated webpage. The translated URL is rewritten by Google’s webpage translation service to end with translate[.]goog, masking the original domain of the malicious webpage. Another notable feature of this style of phishing attack is the addition of non-English text in combination with English text within the email.

Open redirect to credential harvesting using URL shortener and trusted hosting site
Adversaries used compromised accounts of legitimate users of a legitimate company to send phishing emails with embedded malicious links. This is an example of a third-party vendor phishing attack, where the target of the phishing attack either already is using the compromised vendor’s services or products or it seems highly likely that there would be legitimate business need to communicate with the vendor through email.

Compromised email using QR code links/file smuggling using space vector graphics (SVG)
Adversaries used built-in tools such as JavaScript and SVG to smuggle files into the downloaded files of a user. The file may be heavily obfuscated or broken up into many benign parts that become malicious when combined, and this technique can bypass traditional file scanners.

Security gaps? We got you.

Sign up for our monthly email newsletter for expert insights on MDR, threat intel, and security ops—straight to your inbox.


 
 
Back to Top