There appears to be a world-wide increase by a group of actors running
phishing attempts, and then abusing the email accounts to further spread
this.. we are tracking a couple of actors, but more involvement might be
needed from law enforcement.
Most notably, they phish from compromised email accounts, accessing them
from open VPN's and Proxies. (and yes, that is the most of the Google
and o365 Sourced Phishers, but really disappointing .. they have the
budget to identify/stop them.)
There entry points? These guys are really serious..
* Sniffing Tools, on unencrypted traffic
* Password Re-Use testing
* Brute Force and Dictionary Attacks
* Phishing
We are still having troubles attributing this to a single threat actor
group, or several using similar methods.
Each of these have different mitigation techniques of course, as well as
the detection of compromised accounts. And the following ones are the
most common and easiest to implement, without forcing complex or
revealing 2FA implementations. Do the easy stuff first.
* Turn off allowing unencrypted authentication (eg POP 110)
(90% reduction in compromises seen from ISPs who did this)
* No longer allow username only authentication
Password reuse attacks test username/password combinations from other
exposed databases, and routinely try testing every mail server in the
world for a user 'micheal' that has a password of xyx
* Authentication Rate Limiters
It is still hard to 'block' the IP involved of course, given all the
NAT out there, and random EHLO generators, but there are some advanced
tricks.
* Weak Password Prevention
Don't really buy into the you need 16 character passwords.. and users
hate complexity.. but let's make sure they can't use 'test123' or the
128 passwords currently used in most Brute Force attacks. Most
password complexity testers are good enough. You don't have to worry
about hashing strength, unless you have a bad employee with access to
to the encrypted passwords.
* Authentication restrictions... We have long gone past the days of
country auth blocking, it is only helpful against IoT bots.. but
it can't hurt. Several big bots, can increase the number of brute
force attempts without triggering per IP restrictions.. but typically
once they crack the password, the bot hands off the actual abuse of
that email account to an engine in the cloud.. see a lot of that on
google cloud, and AWS IPs.. HINT: block all authentication from
*.google-content for instance.. Real humans don't live in the cloud,
just make sure that you have an exemption override just in case, for
known systems that need to relay. And ESPECIALLY, block all
authentication from known offenders.. eg SpamRATS! RATS-AUTH,
and SpamHaus or SpamRats DROP lists. (SendGrid, you could really use
that too)
* Outbound Rate Limiters.. your first line of defense.. everyone asks
what a reasonable outbound rate limit is.. well aside from ESP's of
course, or mailing lists.. the average user will never send more than
100 messages in a five minute interval, or 500 a day. Keep that limit
in place, and it will be less likely your server ever gets
blacklisted. Of course, you allow a per user or per IP exemption.
Active Filtering is good, but labour intensive. As good as they are,
things like SpamAssassin and Rspamd are not enough.. threat actors have
new templates weekly.
And this latest threat actor, (we are tracking him/them simply as
BADGUY) has now obviously adapted AI to recreate the templates and lures
frequently. (No, we are NOT seeing AI instream used yet, primarily in
creation of templates. And 99% is still the obvious phishing, for
'security' sake 'update' etc.. very little personalized phishing, spear
phishing.
There are services which create updated SA rules almost daily to target
phishing, KAM of course is well known, but there are others.. even our
own company that offer different channels for filtering.
AI of course has a role to play here, it can handle 'intent' better, and
identify common 'tricks' used.. but of course, doing this inline is hard
from a performance perspective, not to mention privacy issues.. We are
working on it, as well as many others..
And REDUCE the NOISE..
Put rules as early in the network conversation as you can. Stop ALL
traffic from DROP lists at the network layer. Use RBL's at the service
port levels if you can, but at least use them in your AUTH layers.
Eg, if you do NOT have customers ever logging in from china, use country
information to block them.. there are MILLIONS of bots.. or there are
RBL's available to do the same.. (If you don't know how, ask)
If anyone want information on BADGUY characteristics.. feel free to ask,
but this is a worldwide problem, and impacts the trust involved in
email. Not to mention, further drives email into consolidation by a few
players.. probably why they let so much malware leave their networks..
trying to drive the little players into submission...
Long winded I know, but hopefully this helps other players in the email
space
On 2025-11-20 00:37, Benoît Panizzon via mailop wrote:
Hi List
Yesterday we noticed our email abuse counter measures having a busy day.
It always started with a successfull SMTP auth and an email sent with
Subject
SMTP Ripper | Valid SMTP Found
or
SMTP Cracker User-ID Num: [HEX-STRING]
sent to different gmail.com address.
Shortly after multiple source IP attempted to start sending spam or
phishing email - almost immediately triggering our countermeasures.
I am a bit surprised that so many customers suddenly fall for phishing
emails. I more suspect the victims use the emailaddress with SAME
password for authentication with some other services which were victim
of the recent huge data breaches?
--
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Reg. TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada
_______________________________________________
mailop mailing list
[email protected]
https://list.mailop.org/listinfo/mailop
