We got hit by an alarmingly well-prepared phish spammer

January 28, 2025

Yesterday evening, we were hit by a run of phish spam that I would call 'vaguely customized' for us, for example the display name in the From: header was "U of T | CS Dept" (but then the actual email address was that of the compromised account elsewhere that was used to send the phish spam). The destination addresses here weren't particularly well chosen, and some of them didn't even exist. So far, so normal. One person here fell for the phish spam that evening but realized it almost immediately and promptly changed their password. Today that person got in touch with us because they'd started receiving email bounces for (spam) email that they hadn't sent. Investigation showed that the messages were being sent through us, but in an alarmingly clever way.

We have a local VPN service for people, and this VPN service requires a different password from your regular (Unix and IMAP and etc) password. People connecting through our VPN have access to an internal-only SMTP gateway machine that doesn't require SMTP authentication. As far as we can tell, in the quite short interval between when the person fell for the phish and then changed their password, the phish spam attacker used the main password they'd just stolen to register the person for our VPN and obtain a VPN password (which we don't reset on Unix password changes). They then connected to the VPN using their stolen credentials and used the VPN to send spam email through our internal-only SMTP gateway (initially last evening and then again today, at which point they were detected).

Based on some log evidence, I think that the phish spammer first tried to use authenticated SMTP but failed due to the password change, then fell back on the VPN access. Even if VPN access hadn't been their primary plan, they worked very fast to secure themselves an additional access method. It seems extremely likely that the attacker had already researched our mail and VPN environment before they sent their initial phish spam, since they knew exactly where to go and what to do.

If phish spammers are increasingly going to be this well prepared and clever, we're going to have to be prepared for that on our side. Until now, we hadn't really thought about the possibility of phish spammers gaining VPN access; previous phish spammers have exploited some combination of webmail and authenticated SMTP.

(We're also going to need to be more concerned about other methods of obtaining persistent account access, such as adding new SSH authorized keys to the Unix login. This attacker didn't attempt any sort of SSH access.)


Comments on this page:

By Allan Wind at 2025-01-29 03:29:55:

You may want say something to bridge the story gap from user receiving a phishing email to user sharing their password with the attacker. How did the user subsequently realize that there was problem? Anything to learn from that? If you can read headers (return-path, received, dkim and spf) you have a chance but these days with cloud services even that becomes problematic. Is there a way for an external party to tell which vpn solution you use? If not maybe they probed the most used ones. I am certain that you cannot block 100% of these phishing attempt. This leaves some type of one-type password as the only realistic defense.

By Skaarj at 2025-01-29 07:11:51:

My first idea would be turning off the SMTP gateway that doesn't require auth.

I assume there are some reasons the SMTP service is still around?

By cks at 2025-01-29 13:06:32:

Based on what the person told us, the phish password capturing and the detection story is more or less what you'd expect. The actual phish's core message was 'N email messages are waiting to be delivered to you, click here to view them' with a link to a phish site that asked for your login and password and then told you that they didn't work (causing the person to try several times). After the person had tried several times on the site, they realized that they'd fallen for a phish and this wasn't our real site.

As for information on our VPN setup (and our mail sending setups), it's on our support site (for obvious reasons) so we assume the attacker read it in advance. Internally we made some dry jokes about this making the attacker somewhat unusual.

(There are various reasons we have an unauthenticated SMTP gateway. It exists both for various sorts of internal use and for historical reasons.)

By concerned at 2025-01-29 13:13:56:

no MFA on VPN connections?

Instead of a vpn that allows rarely-changed passwords, I'd suggest experimenting with tailscale.

It is a vpn-like-thingie, from Canada, written and run by Avery Pennarun (apenwarr@tailscale.com). It looks good, and i's layered on wireguard-go.

I experimented with the free version on my laptop and phone, but that's a sorta small network to draw any conclusions from.

Written on 28 January 2025.
« How to accidentally get yourself with 'find ... -name something*'
Our well-prepared phish spammer may have been chasing lucrative prey »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Tue Jan 28 23:24:36 2025
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.