We got hit by an alarmingly well-prepared phish spammer
utcc.utoronto.ca
utcc.utoronto.ca
Turns out there's a lot of fake shell companies that act either as hosting companies specifically for malware campaigns from Russia and China or specifically as a company that tries to fraud people, e.g. their CEO being on the FBI most wanted list or the company being sanctioned by the UN.
I'm currently creating some sort of cyber map of these spam/phish/malware campaign overlaps, as part of my antispam [1] effort.
I got tired of LLM based targeted spam where they have a system in place that is trained on my social media profiles, because they are very hard to identify as being spam.
Blocking specific domains is a useless effort because they keep on spawning new fake company domains that are either copies of legit ones or are generated fake profiles. They are so automated that they also create staff members and fake profiles on LinkedIn, specifically for that spam effort. Nobody at LinkedIn gives a shit about those fake avatars, I reported hundreds by now and they did absolutely nothing.
Anyways, long story short, here's the blocklist of those ASNs and companies. I'm working on the map at the moment and don't wanna publish it until I can prove its correctness:
For every account I create on the internet I create a new mail inbox, this way I can just compare the email title with the inbox it was sent to. So, when I receive a notice from my bank on my github email I know what happened. This genuinely saved me a few times already.
I've caught a couple of hacked or sold email lists, but nothing that drastic yet.
One organization posted the email address I gave them on a public contact list webpage, so I get spam/phishing at that one.
Using a catch-all is the easiest way to do this, and I highly recommend it for other people.
Most providers let you run a catch-all adress on your own domain. You usually set it up with just a check-box "catch-all" and where to send all mail, or you write the username as "*" in an alias.
Since many sites can't believe that an email address can have a "+", I can also use "anytext@dcoder.users.panix.com" at most sites instead of dcoder@panix.com. ("anytext" typically, for me, being the name of the company or organization that I'm dealing with. Also, my Panix account is not really "dcoder".)
I always give out myname+tag@... to places that ask for email, and have an incoming message rule that puts bare myname@ straight into spam folder.
So far, the only messages to bare address were service updates from my email provider itself.
If you have 'domain.com' you can receive emails either on 'foo@domain.com' or 'bar@foo.domain.com' without problems.
You can even get an api key for it and plug that into bitwarden, so that when you sign up for whatever, you click bitwarden, generate password, generate email, sign in and it's all set. So smooth. (I sound like an ad, but internet pinky promise no affiliation)
I've just explained the problem with the gmail tagging in another comment.
I don't know what they are thinking. Isn't it a real family name in Korea?
That said, are you sure it wasn't the + that caused the problem? I've run into that a few times, presumably when someone tried to roll their own email validation.
gnusmas@private-domain.tld worked just fine..
I'll make these intentional letter swaps every time just to avoid regexes and automatic filters.
The problem is that foo+bar@gmail.com and foo@gmail.com are delivered to the same inbox, so if you are trying to scam someone it is safe to remove anything after the + in a gmail address.
And having a custom domain on gmail doesn't improve your situation, because with just a simple 'dig mx' you can know if the domain is hosted on gmail and apply the same regex to remove all labels.
So, to be less inflammatory the feature works as expected. But it only protects you if the bad actor is really dumb/lazy or if he is honest.
And the 'fuck them, I won't do business with them' attitude doesn't really work if the system that wont accept your email is the local gas company.
And there is another problem, some systems will just remove any label without informing you. I've had this problem logging in some random websites. My account was created with foo+bar@gmail.com but to log I had to use foo@gmail.com.
For those sites, you can add a dot in your username. Then you can ignore any emails sent to an address without the presence of a dot or a plus.
I'm sure there are sites that don't accept dots either, but I've never run into one. So you have to make an exception? Oh well.
I agree that it's easiest to do with service@domain.tld, like the grandparent suggested.
+ sign is part of the standard (`atext` token, RFC 5322), so sites, which disallow it in address are doing it wrong. The fact, that industry adopted a practice of using everything after + sign as a "tag" is not captured anywhere so this creates even more mess in already messy space (e.g MS followed GSuite in this too and added subaddressing - https://learn.microsoft.com/en-us/exchange/recipients-in-exc...)
The problem, however, is that most companies still rely on crappy Enterprise services like Microsoft Office. For most people managing identities like this is impossible to do - due to either lack of user-friendly options or due to too high thresholds of necessary IT knowledge.
I mean, we are speaking about having to configure Dovecot and Postfix and similar tools, and I fuck that up regularly. And we are also assuming that they have to be unguessable (you have github@? maybe I should target linkedin@, too, then!) which implies that they have to be random-looking which means they will likely be blocked by registration filters.
Newer projects like Maddy [1] kind of go towards that direction, but are still targeted at developers or sysadmins.
'Creating a new inbox' was an exaggeration on my part. What I have is a catchall on my fastmail account. But when I talk about creating creating inboxes it seems to make it easier for normal people to understand what I'm doing and the benefits it brings.
> we are also assuming that they have to be unguessable
That would be nice, but I don't have a nice way of doing it. I've tried to use something like rot13 to make it less obvious, but it is a pain to manage it. It would be nice it existed a cypher that was pretty easy to do in my head, but I never found anything like this.
> you have github@? maybe I should target linkedin@, too, then!
Yes, this is a problem. For a targeted attack this may become a weakpoint in my defense. But this is a calculated risk I'm willing to accept for now.
It's especially hard now that many legitimate companies use a lot of generic sounding AI-generated content, which seems to be same approach the spam/phish/malware teams are using.
IMO we need some kind of zero-knowledge proof system that can be checked to verify if a message sender is a US citizen, employed by who they say they are employed by etc.
I don't see how we can trust anything in a post-generative AI world any other way.
I think this could be a great opportunity for Google. Lots of organizations already make use of Google Workspace/Gmail. Imagine if Google Workspace offered the equivalent of a "Twitter blue check", where you pay extra, and anyone who views your email in Gmail sees a little check mark next to it, that shows Google verified you are who you say you are, and Google thinks you're not malicious. Salespeople sending cold emails would love it.
I don't think you can solve this problem purely cryptographically. An attacker could always bribe a US citizen to set up a shell corp or whatever. Most objectively verifiable indicators can be gamed. There has to be an organization that's good at security, like Google, which is in the business of continuously keeping up with adversaries. Actually Google might not be the best because they kinda suck at tailored customer service, but anyway.
Ha. Same here but reporting a job ad that targets the dublin area, but it's really for bangkok. I hate it.
So you have to focus on process and systems. Some easy stuff:
* Never ask customers/employees for a password. If someone does it's a scam.
* Refund money only to the payment method used to pay for the product/service.
* 2FA is your friend no matter how much the VP of Sales whines about it.
* have a way to expire tokens and force reset of passwords.
Not every reset is due to expiration... e.g. if you know a user reused a password from a different service that got hacked on your service, you should probably make them reset it...
Good example:
> Navy chiefs conspired to get themselves illegal warship Wi-Fi [0]
[0] https://www.navytimes.com/news/your-navy/2024/09/03/how-navy...
Time to clean that up while you're at it.
It makes no sense that you'd keep an insecure service because you forgot someone needs it. You turn it off and the reminder will promptly come to you. After this it's a decision, not oversight.
> It’s nothing to do with costs, its just an oversight
The article suggests that their internal unauthenticated SMTP was there by design, not oversight, together with an authenticated (presumably external) one. Some assessment deemed addressing the risk from the unauthenticated internal one not worth the cost and effort.
> People connecting through our VPN have access to an internal-only SMTP gateway machine that doesn't require SMTP authentication [...] previous phish spammers have exploited some combination of webmail and authenticated SMTP.
You’re assuming an org that had a policy my in place for this which was followed all along, and not that it’s a piecemeal service barely held together by dreams and prayers. My experience with university It departments is there’s an _incredible_ amount of “dunno who that belongs to but don’t touch it because it might be important” going on.
Right, so not an oversight, but a decision not to touch the obscure system. Decisions with bad outcome aren't oversight unless you want to downplay them when justifying yourself.
Your SMTP gateway is never "that" system that nobody knows about. You must know who owns and manages it, you know you have to secure it (minimal measures like... authentication) so you don't get unceremoniously penetrated. And if you do it you may or may not realize that something will fail because of the extra security.
If you know that "one cobbled together system, or old network MFP" I was mentioning earlier will fail when you enforce authenticated SMTP, because it's too old and replacing it is $$$, or too arcane and bringing an expert is $$$ then you will take an informed decision whether to proceed with your security hardening or not.
If you have no idea something will fail (you didn't catch it in the dry runs) if you enforce authenticated SMTP, you just do it and if someone comes in a frenzy to tell you that the old and arcane system is down then you revert the change. Now on you're in the informed decision scenario from above.
This is not a minor omission. Leaving a glaring insecurity like this open by oversight isn't what the article suggests happened, and it almost never never the case. It's not something that "just happens", it's something that people meet to discuss about and decide to ignore it maybe for reasons that look good at the time. This is the essence of risk taking. But it's a decision nonetheless.
2. As for the rest, take them down one by one and see what breaks. Got a call to internal support hotline? "Ooops, sorry, we will turn it on and let's chat about it soon."
There can be a few announcements in advance to shift the blame before (2): "Declare yourself or face consequences" (ChatGPT will write a nicer email). If you are on good terms with CFO, the noise won't matter. In fact, many people will thank you, when their weird stuff is taken over for care by IT.
Nothing was exposed to the Internet, but one of my small fears was seeing spam in the log of that service, that would mean a serious breach.
That's what "every system should be authenticated and authorized" feels like in the limit. So in practice, it always boils down to how deep you go before the overhead starts to eclipse any benefit you get from running the system.
Switching to a modern stack is not just a matter of choosing the summiting. This is easy.
You then must know what days you have. Still manageable somehiw.
Then the processes, maybe the company as a while know all of them (maybe) but this is dispersed amon plenty of staff.
Then you have dependencies. You close z door and a building collapses 10 km away.
Finally there is everything you do not know about many someones added.
Don't get me wrong : I work in cybersecurity. But I know how complicated things are.
Old java based application that doesnt respect all email flags and will often just close the connection even mid successful auth.
New server that lives in the cloud, but doesnt match up with the right protocols to send email out of Azure and into 365, so its punted down to on prem and back up to 365 just so Microsoft can sleep better at night.
These are the most common reasons I have seen.
Physics.
Laziness.
Forget authentication, I know some people who leave their car key in their car and their front door unlocked because they can't be arsed.
For myself, my personal and professional contact lists wouldn't be pleased, and I would apologize to them, but it's not going to cause me to lose any money. I'm certainly not going to be embarrassed about nudity or body shape/condition. Everyone is nude under their clothes, and other people have the same body shape or maybe even medical conditions. (Unhygienics is something else though, and that would be unpleasant.)
Also, I don't let anyone take nudes of me, nor do so myself, because it's just easier to assume that anything digital might be hacked one day.
They don't have to compare, they are both problems.
> Physics.
> Laziness
Redundant. Physics says an object in motion wants to stay in motion and an object at rest (a lazy object, if you will) does too. Ergo, laziness is a property of physics. QED
I'd have thought there would be a lot more that could be done with VPN access than immediately burn it by sending spam.
The prize is sending phishing e-mails that are indistinguishable from authentic e-mails. E-mails where every check and signature says they really come from the university's employee pensions team, or the IT accounts team, or the legal team.
Distraction. Like a magician.
This part sounds... not great. Even bad actor within org could send messages as someone else: president to payroll etc.
Cool, but hey get this... I'm interviewing next week some guys working in API security. and the discussion notes so far are terrifying.
People do all this work to build secure networks and OS, and then someone says "Hmm we need an API for <fashionable reason>", and next thing a junior dev exposes all the top level functions of a program running with high privileges as URL handlers.
So maybe even _within_ your app it's not too paranoid to think "what if someone got an entry point into this function?" and at least put a "NEVER EXPOSE" comment there :)
If your system is on-premises, you may reasonably assume that the attacker will need to read the man page, like a new employee, see? But these guys didn't need to read the man page.
This is the kind of dumb stuff we were doing 30 years ago: making the assumption that being physically on the network implies authentication.
There's zero excuse to have a no-auth SMTP server, or anything else for that matter.
For the typical hacker or foreign service this went as expected. Just that they detected it very soon, so not much harm done. Only VPN
The phishing emails we get at my software dev job for security certification and pen testing pale in comparison to the actual effort being put in by scammers, who coordinate bookings with parcels and random invoices so that they tell a story, always targeting different shifts (almost never the same).
Other simple stuff is overdue payments for fictive deliveries such as soaps, toilet paper, cleaning bills or even outsourced work.
The more complex scams involve making bookings and sending packages with fees and totals paid by the recipient, they try to convince the receptionists that their package needs to be delivered, and an actual delivery of random stuff happens using a real delivery company to complete the scam. They don't always mention that there's payment required on delivery.
Other scams involve claiming lost luggage, wallets, electronics without them being the owners, and trying to convince the receptionist to send the item internationally. We're a hotel next to the airport, so international travellers are the norm, plus we have a room full of lost stuff. They make a booking with a fictional name, then cancel it or no show, and then ask for their black luggage, black wallet, tablet, gold bracelet, etc.
I'd be interested in hearing how folks find working with "zero trust"; my employer's adoption of a zero trust VPN has been pretty bad, but I don't know if it's normal.
In my company, it's made it much harder to give decent support to users; previously, a user knew if they were on the VPN or not, and if they were on the VPN but they couldn't reach our service, that was a very rare event and it lead to a P1 outage getting an immediate response from a senior engineer.
Now, users don't know if they've passed the device posture checks or not - user plugs in their phone to charge it? Unauthorised external storage device, silently reduce their network access. So now if a user knows they're on the VPN but can't reach our service, that's very common; it's a P4 issue and within a 4 hours an intern will tell them to reboot their PC and try again.
Apparently users can't be told when they've failed the device posture check or why, for 'security'.
Needless to say, the engineers hate the much larger support burden, and the users hate the the much slower and less helpful responses.
Is it supposed to suck this much?
Weren't there implemented protocols to use the devices connected to the VPN that would proof against the most common sources of posture check failure? I imagine most problems are quite trivial, like the phone you mentionned, especially if treated as P4 (there might wven already be a document with the required advice used by the interns when telling people to reboot).
No, and this isn't the concept of Zero Trusts fault. This is inexperience and/or a lack of competency from your security people and your support people. Although, more likely given that two "silos" are impacted, systemic organizational issues that aren't going to go away.
i.e. isn't the fact you can be on the VPN yet blocked from accessing the service the goal of Zero Trust?
I wonder how it might work out, if Hollywood produced a "Breaking Bad"-style series, about an ambitious young cybercriminal moving up into the really big leagues.
I'm waiting for the biopic of Ross Ulbricht. It's got all of the bits that Hollywood loves with the young protagonist breaking bad, FBI agents also breaking bad, and now comes with a guilty conviction turning into a full blown pardon.
There is a global cyber war going on.
War is something entirely different. The belligerents are not trying to disable agricultural systems or power grids; an actual war is a horse of a different color, and would likely be regarded as a proper escalation in the physical realm.
Probably the best example, is the current conflict with Russia and Ukraine. It's a global cyberwar, with real (life and death) consequences.
https://blogs.microsoft.com/on-the-issues/2022/04/27/hybrid-...
https://blogs.microsoft.com/on-the-issues/2022/06/22/defendi...
It's not unrestricted cyberwar, but I also don't think we have a complete picture of the scale of the cyber conflict, nor do we have a complete picture of the attacks and defences being mounted.
There have been any number of attacks on physical infra. and civil institutions that fit that description. Sandworm (a group in the Russian military) alone has successfully brought down power grids multiple times.
Uh, no. There have been a massive number of attacks attempting to take down the power grid. It's just that the protections in place are currently working most of the time.
Unfortunately, the official stats tends to combine both physical and cyber attacks, so there's no clear sense of which is dominant... But, frankly, there isn't a need to separate them. The attacks are happening.
[0] https://www.politico.com/news/2023/09/10/power-grid-attacks-...
Requiring admin approval for VPN accounts would have prevented the phisher from getting VPN access to begin with.
On the other hand, those attackers are probably less malicious than the average Russian ransomware group.
"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."
That really changes the level of complexity for the attacker here
As someone else said, I would increasingly suspect that apparently targeted or seemingly highly-invested hacking behaviour is just a new breed of scripts that are puppeteer by phishing AI multi-agent systems (maybe backed by deepseek now).
Just like self driving cars that will never make the same mistake twice, these things will likely keep a catalog of successful tactics, and so always be learning obscure new tricks
AI is available to everyone, and we’re not prepared.
- shut their accounts off network-wide
- drop all related network connections
- forcibly reset their password and make them choose a new one in person. They may have changed it earlier, but do it again
- increase logging to catch any potential reoccurrences against the same user or other users
- inspect ACLs and reduce access for all users if possible
- prevent users from connecting from areas outside of their usual network sphere
- let the user back on, and ask them to be more careful in the future
- better mail filtering would be nice, but they'll always find a way to beat the spam filter
- (i hate this option the most, but...) send fake scam emails internally to see if anyone else takes the bait
This is of course ignoring 2fa, but 2fa isn't perfect either with sim swapping... but I personally don't think changing the password is enough for an event like this.
Why not just use Duckduckgo's free e-mail protection? Generate a new forwarding address for a new service/website/account takes a second.
I figure these kinds of relationships are determinable from linkedin etc., but they're still automated. Using family members seems like an extension of this technique, sending phishing from someone you probably know.
it help alot against these type of scenarios.
also, how fast is fast? you can scan an internal network on a single port in the blink of an eye, so if u don't have good network IDS/IPS internally, u will not really see the scan and it seems like someone 'knows the network in advance' because they scan it in like 2 seconds and based on results automatically run scripts etc. - it doesn't need to be knowledge gained in advance.
- monitor internal network properly, asif its external network. - use ztna+ if you can afford such solution - do regular audits for things like unauthenticated services and use these kind of incident to in a friendly manner educate sysadmins about risks of such services. they will usually understand it, especially after an incident. aslong as you bring it friendly with a good explanation, not some demanding attitude.
- use a lot of mail filtering... more is better. it can be a bit tedious. at my company we have more than 4 solutions to scan all email and attachements etc. , still stuff slip through, but not a lot... - also scan outbound or 'local' email. (BEC fraud etc.)
- do good post-incident reviews and use learnings each time something happens (sounds obvious, but this is often omitted, the learnings are only kept within sec teams, or turnt into one-off remediations rather than process etc. )
edit: oh.. and also monitor for logon anomalies. a lot of solutions support this. e.g. a user logs in from a unique new ip - alert on it, or even block it. , that action depends a bit on what's normal, so here actually ML and such solutions are great.. but basic statistical analysis etc. can also help if u can't pay or create ml solution. (its not too hard to create really, basic models will suffice.)