Handling an ExpressVPN Login

This is another success story, but this time the “bad guy” is the amount of time and effort it would take you to do what we do painlessly.

The best way to handle remote access is with trusted, managed devices, strong authentication, locked down where employees can’t install any software (especially privacy VPNs), with full geo-tracking, and conditional access policies blocking logins from anywhere except known travel on those managed devices, with ample planning… but that is challenging for many organizations for a variety of reasons. The reality is, your organization has a culture, and that might mean to trust your employees to do certain things, or it might mean you cannot afford all of the controls and time to lock down those controls.

So what do you do when an employee logs in from their Windows laptop, which isn’t managed by an MDM solution (so you can’t know for sure it’s their company issued device), from a brand new location for the first time, on a privacy VPN they’ve never used before?

That’s what happened for one of our customers yesterday:

Case Summary We know it's benign now, but we didn't know at the time it happened!

For most companies, the status quo is to completely ignore these types of detections, because it’s just so hard to know where your users are. It’s often perceived as a privacy “big brother” issue to track a company’s device, or worse: an employee logging in from a personal device using a BYOD approach.

For MDR/MSSP providers, it’s 100% the standard quo to ignore these. If their customers can’t know where their employees are, they certainly don’t have much of a sporting chance, right?

The best organizations will capture metadata (like what we have in the screenshot below), that shows statistics around how often a given IP Address, or its ASN (the network the IP belongs to) have been used to successfully login. When that doesn’t bear enough fruit, they’ll dig deeper into other metadata, like user agents and locations, but that data is much more of a leap of faith to trust.

We refuse to give in so easily. Take a look at the actual timeline from the case:

Case Summary The metadata of this login is not conidence inspiring!

[Note: there was a bug in how we captured the timestamp when Microsoft made it available, so this looks like we had an ingestion delay for much longer than we actually did. Microsoft shipped these timestamps on that case: “activityDateTime”: “2025-05-12T21:08:10Z”, “detectedDateTime”: “2025-05-12T21:44:06Z”, “lastUpdatedDateTime”: “2025-05-12T21:54:30.7788302Z” and we should have used the lastUpdatedDateTime value as when it was “made available” because our ingestion delay was only about 1 minute. When “speed” is in your name, details like this matter!]

Is there a known managed device at the public IP right now? No.
Has that IP address been used to login successfully? Yes, but only once, don’t count on that!
What about the city? Many times, but it’s San Francisco, so there are millions of matching IPs in that city, definitely don’t trust that!
What about the user agent for browser? Nope, never used before!
What about the ASN for that IP address? Yes, but with only a 79.6% success rate

So, what did we do? ChatOps. We sent a quick broadcast over Teams and Email (the customer’s chosen platforms), directly to the affected user—not the security team at our client! The customer responded in about a minute that they did in fact just login at that location with ExpressVPN.

But the story doesn’t end there …

How did we know it was really Jane Doe and not an imposter who had taken over the account? Because we performed out-of-band multi-factor authentication to validate them. In this case, we knew the initial login was using Microsoft Entra, that the user has a valid mobile phone number, and that the number hasn’t changed in a long time, so it’s safe to send a One Time Passcode (OTP) via SMS text. If the number had recently changed, we would have assumed a bad guy on the other end of the connection. Why? Because that’s what I did many times before in my Red Team days.

#Bottom Line

We took a complex scenario and turned it boringly mundane. We validated a good guy in a relatively painless way. The security team at our customer never had to get involved, never had to interrupt their day … and ironically their leader was even out on PTO when this happened.

This is the way security should be. Simple. Effective. Democratized out to the affected users, protecting a critical resource: the time of your in-house security team.

Want to learn more about how Wirespeed can make security painless for you? Contact us to start a FREE TRIAL today.