Investigating a Suspicious Login Using WHOIS and DNS Tools

At 10:45 AM on a busy Thursday, our security dashboard popped up an "Impossible Travel" alert. Our Senior Director of Finance had logged in from our Chicago headquarters at 9:15 AM. Then, at 10:30 AM, his account successfully logged in from Stockholm, Sweden, using the IP address 193.180.118.6. The distance between Chicago and Stockholm is roughly 4,250 miles. To travel that distance in 75 minutes, a plane would have to fly at over 3,400 miles per hour, which is physically impossible for any commercial aircraft. If an attacker had compromised his session token, they could access our internal financial systems, bypass our Multi-Factor Authentication (MFA), and execute wire transfers. We had to act fast.

Triage and Network Investigation

In modern corporate security, session hijacking is a major threat. Scammers don't need your password anymore; they use phishing or malware to steal the session cookies active in your browser. They import those cookies into their own systems and gain instant access to your logged-in dashboards. Since the session is already active, Microsoft 365 doesn't prompt for MFA. The login looks perfectly valid, except that the connection comes from a different country. We immediately suspended the user's active directory account, killed all running Microsoft 365 OAuth tokens, and started digging.

We had to determine if our director was actually in Sweden or if his account had been compromised. I grabbed the Stockholm IP 193.180.118.6 and ran a WHOIS Lookup on IPDekho. The registration records showed the block fell inside the subnet 193.180.116.0/22, registered to Bahnhof AB (AS8473). Bahnhof is a well-known, privacy-focused internet provider in Sweden, famous for hosting services inside underground nuclear bunkers. Because Bahnhof sells residential broadband, corporate fiber, and server hosting, the IP address wasn't as easy to classify as a standard cloud host like AWS or Azure.

To get a deeper understanding of the network block, we pulled the WHOIS details. The records showed the parent organization registration was: NetName: BAHNHOF-NET NetRange: 193.180.116.0 - 193.180.119.255 CIDR: 193.180.116.0/22 Country: SE This subnet allocation confirmed the target IP was hosted in Bahnhof's Pionen facility in Stockholm. This datacenter is built inside a former Cold War civil defense shelter, 100 feet below the street level, protected by heavy steel doors and backup generators, making it a highly secure location often used by privacy services.

Checking Pointer Records and Ports

We needed to find out if this IP was running public services or if it was a VPN exit node. I ran a Reverse DNS Lookup on the IP address. The PTR record resolved to "vpn-exit-node.se.bahnhoff-customer.net". The host naming structure literally had the words "vpn-exit-node" printed in it. This was a massive clue. It meant the IP belonged to a commercial VPN provider renting server space inside Bahnhof's data centers. A reverse lookup maps the IP address back to a human-readable hostname, exposing the domain registry records that providers use to label their outbound gateways.

To double-check this, I ran a quick Port Scan on the IP. A home router or normal worker's device will have all incoming ports closed. But a VPN server has to keep ports open to accept user connections. The scan confirmed our theory: - Port 80 (HTTP): Closed - Port 443 (HTTPS): Closed - Port 1194 (OpenVPN): Open - Port 51820 (WireGuard): Open This list of open ports is characteristic of an active VPN gate server hosting OpenVPN and WireGuard protocols.

The open OpenVPN and WireGuard ports confirmed the target was a VPN node. The attacker—or our director—had routed their web traffic through Stockholm using a personal VPN.

The Confession and the Fix

I called the director directly on his mobile phone to verify. He laughed and confirmed he was sitting in his office in Chicago. He was trying to debug access latency for a Swedish accounting tool our team uses, so he connected to a Stockholm VPN server and forgot to turn it off before opening his corporate dashboard. The alert was a false positive. We un-suspended his account, had him log back in, and closed the ticket.

The incident ended up being harmless, but the investigation process showed how having the right tools makes all the difference. By combining WHOIS logs, reverse DNS lookups, and port scans, we verified the VPN signature in under ten minutes. Knowing whether an IP is residential or a VPN node is key to managing security alerts in a remote-work world, helping security teams separate real threat alerts from harmless employee developer activity.