We caught an attack where the first successful login we saw for a user was malicious.

How we could be sure this was an attack? After all, we had no baseline for this user …

Let’s dive in.

This is all the data we had for the user at the time of the attack:

• 1-26-25: Failed login to Microsoft Azure CLI from Hurricane Electric LLC, a data center in Mexico

• 1-29-25: Successful login to Microsoft Azure CLI from different IP in the same data center

From just these two logins, it’s pretty tricky to tell whether this is expected behavior or an attack.

On one hand, command line logins usually come from people running cloud computing workloads in data centers. Programmatic workloads also often rotate IPs using tools like FireProx.

On the other hand, this could be an attacker who compromised this account with a brute force script. Perhaps they’re using the data center to run a large scale attack campaign targeting users all over the world.

The key to solving this case is to look beyond this single user and examine all the recent activity in this tenant.

When we look at all the logins for this tenant from Mexico, we see an attack campaign hiding in plain sight: this attacker targeted 24 distinct users using Microsoft Azure CLI.

They tried every user no more than 2 times to avoid setting off any brute force detections.

They also used a slew of IPs from the range 2001:0470:c8e0::/48 to evade any IOC-based detections.

The repeated failed logins across multiple users, combined with clear attempts to avoid triggering alarms, make it clear that this is an attack.

We would have missed this if we just analyzed the activity timelines for each individual user.

Slicing Microsoft’s logs in creative ways allows us to unmask attackers hiding in plain sight. In this particular case, shifting our perspective from user activity to tenant-wide activity was the key.