subject:"\[mailop\] Compromised email account trends"

Re: [mailop] Compromised email account trends

2023-02-24 Thread Taavi Eomäe via mailop



Please educate us: how can a standard-compliant MUA use OAuth2 without 
the developer registering the MUA with each service provider they want 
to support?


By implementing RFC7591, OAuth 2.0 Dynamic Client Registration Protocol, 
which allows MUAs to do this automatically.


But as mentioned in the second subthread, not what I meant entirely.



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Compromised email account trends

2023-02-24 Thread Michael Peddemors via mailop


Tried to stay off this thread..

However, a lot of talk on the subject, and I guess time to mention on 
this thread..


2FA needs to be simpler.. transparent to the customer.

It's one of the reasons that we first suggested adopting changes in the 
legacy email protocols, so it can better support this.


And at M3AAWG, several list members asked about the location of the RFC 
Drafts covering this..


https://datatracker.ietf.org/doc/draft-storey-smtp-client-id/
https://datatracker.ietf.org/doc/draft-yu-imap-client-id/

Simply put.. (Thanks to a M3AAWG member who described it like this)

Think of it as a 'cookie' for SMTP/IMAP.

I "prefer" if discussions on the spec, it's current adoption, remain off 
the mailop mailing list, but I think you can see it is at the heart of 
the discussions in this thread, eg on what it is intended to do.


(Reach out off list if you want more information, or discuss on the IETF 
channels for this)


We encourage all email clients and email servers to support these 
extensions...


But at the end of the day, simple transparent 2FA is the holy grail, and 
of course stops 99.9% of password spray attacks, brute force attacks, 
and most email leakage attacks.


You just have to make it easy to add/revoke/register devices.

Too bad about the 'what happens at M3AAWG, stays at M3AAWG' in this 
case, because some really great conversations were had on this topic, 
that would be great to share..



On 2023-02-22 11:03, Sebastian Nielsen via mailop wrote:
Problem with OAuth2 is that many commercial mail clients only support it 
for a select number of big providers thus you have 2 choices, either 
implement geo-restriction, or have a 2FA auth portal where you authorize 
IPs to access your account.


 Originalmeddelande 
Från: Taavi Eomäe via mailop 
Datum: 2023-02-22 19:42 (GMT+01:00)
Till: mailop@mailop.org
Ämne: Re: [mailop] Compromised email account trends

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop



--
"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 Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Compromised email account trends

2023-02-24 Thread Bill Cole via mailop


On 2023-02-22 at 09:56:40 UTC-0500 (Wed, 22 Feb 2023 14:56:40 +)
Gellner, Oliver via mailop 
is rumored to have said:


On 2023-02-22 15:08, Giovanni Bechis via mailop wrote:

I have also one more idea. Remember the old "POP-before-SMTP" 
approach

from the times there was no SMTP AUTH yet? I have observed that the
password-cracking bots are heavily attacking submission services,
while relatively very rarely trying to login to IMAP service. On the
other hand, any regular email client first does IMAP login to get 
the

mailbox index, and then after the user tries to send a message,
authenticates to submission service. So one might simply reject 
*any*
password on submission service, if there is no recent successful 
IMAP

login to the same account from the same IP address.


this would not work for me, on my servers ~6% of imap logins are from 
bots.


Also you have to consider CGNAT scenarios and other setups where the 
egress IP address of a user might change, which would cause 
intermittent, unexplainable breaks when trying to send emails.


An issue with any OOB authentication tied to an IP. A compromised 
Windows laptop behind a company-wide NAT has no problem mimicking the 
other Windows laptops around it which are all using the same IP as 
clients.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Compromised email account trends

2023-02-24 Thread Bill Cole via mailop


On 2023-02-22 at 18:53:02 UTC-0500 (Thu, 23 Feb 2023 01:53:02 +0200)
Taavi Eomäe via mailop 
is rumored to have said:


Why should I need to use a program registered to the service provider
in order to read my email? (Or in my case, register myself as a
developer with Microsoft in order to allow me and my colleagues to
read our own mail.)



You are confusing one vendor's implementation with the standard.


Please educate us: how can a standard-compliant MUA use OAuth2 without 
the developer registering the MUA with each service provider they want 
to support?





--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Compromised email account trends

2023-02-23 Thread Steve Freegard via mailop

Gah - sorry, my work email address changed recently and I forgot to update
it here, so my post to the mailing list bounced and I only just noticed as
I'm at M3AAWG.

This was the blog post that I posted to Jarland that didn't make it to the
list:

https://abusix.com/resources/blocklists/compromised-account-detection-with-abusix-mail-intelligence-and-postfix/

I'd love to hear any feedback on this.   It worked extremely well in my
(rather artificial) testing.

Kind regards,
Steve.

On Wed, 22 Feb 2023 at 02:33, Carsten Schiefner via mailop <
mailop@mailop.org> wrote:

> Sebastian & all -
>
> On 22.02.2023 01:51, Sebastian Nielsen via mailop wrote:
> > Didn't get steve's mail for some reason (guess it was because i forgot
> > to renew exim tls cert, but its renewed now), but replying to it here.
>
> I have also noticed that: this particular email did not pop into my
> inbox either.
>
> After having looked a bit deeper into this, it appears that Steve
> Freegard replied directly and only to Jarland Donnell on 21 Feb, 12:10
> (timezone?).
>
> Jarland Donnell in turn has then replied publicly to the list again on
> 21 Feb, 17:04:02 -0600.
>
> That at least is how I would interpret the present/missing) list footers.
>
> So no mails missed! :-)
>
> Cheers,
>
> -C.
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>

-- 

Steve Freegard

|

Senior Product Owner

T.

+44 7740 364348

abusix.com

Book a meeting

[image: My Logo]

CONFIDENTIALITY This email and any attachments are confidential and may
also be privileged or otherwise protected from disclosure. If you are not
the named recipient, please notify the sender immediately and do not
disclose the contents to another person, use it for any purpose, or store
or copy the information in any medium.

You’ll find further information about privacy here

.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Compromised email account trends

2023-02-23 Thread Giovanni Bechis via mailop


On 2/22/23 15:44, Andrew C Aitchison via mailop wrote:

On Wed, 22 Feb 2023, Giovanni Bechis via mailop wrote:

this would not work for me, on my servers ~6% of imap logins are
from bots.


*Successful* IMAP logins ?

not for bots but, at least my[.]com address space does successful imap logins.
 Giovanni


OpenPGP_signature
Description: OpenPGP digital signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Compromised email account trends

2023-02-23 Thread Taavi Eomäe via mailop


> Really? RFC6749:

Maybe I was a bit too eager with the quote earlier as I was really 
pointing at the "register as a developer part."


Your qualm was that *you* have to register as a developer. How that 
process looks like, how tedious it is and how many MUAs already have 
added support is specific to a vendor and its implementation. It in and 
on itself is not a sufficiently large hurdle compared to the positives.


The reason "why" is probably also described in the same standard. For 
example allows you to let the user know which MUA logged in to their 
account. Maybe they don't use Thunderbird at all - instantly suspicious 
and they can revoke that session without messing up all the rest. A 
random IMAP connection with the usual authentication methods probably 
doesn't provide that info. There's certainly more to it, but that's just 
*one* aspect it makes better than before.




smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Compromised email account trends

2023-02-23 Thread Julian Bradfield via mailop

On 2023-02-22, Taavi Eomäe via mailop  wrote:
>> Why should I need to use a program registered to the service provider
>> in order to read my email? (Or in my case, register myself as a
>> developer with Microsoft in order to allow me and my colleagues to
>> read our own mail.)
>
>
> You are confusing one vendor's implementation with the standard.

Really? RFC6749:

2.  Client Registration

   Before initiating the protocol, the client registers with the
   authorization server.  The means through which the client registers
   with the authorization server are beyond the scope of this
   specification but typically involve end-user interaction with an HTML
   registration form.

[ ... ] 

   When registering a client, the client developer SHALL:

   o  specify the client type as described in Section 2.1,

   o  provide its client redirection URIs as described in Section 3.1.2,
  and

   o  include any other information required by the authorization server
  (e.g., application name, website, description, logo image, the
  acceptance of legal terms).
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Compromised email account trends

2023-02-22 Thread Taavi Eomäe via mailop




Why should I need to use a program registered to the service provider
in order to read my email? (Or in my case, register myself as a
developer with Microsoft in order to allow me and my colleagues to
read our own mail.)



You are confusing one vendor's implementation with the standard.



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Compromised email account trends

2023-02-22 Thread Julian Bradfield via mailop

On 2023-02-22, Taavi Eomäe via mailop  wrote:
> This discussion is getting awfully close to reinventing OAuth2.
>
> It's quite clear by now that long-lived tokens that are nearly 
> impossible to properly revoke just don't work well in any human-operated 
> contexts.
>
> Hopefully we'll see an increase in the adoption of OAuth2 instead of 
> rather crude ways of mitigating only half of the issue. Large players 
> started pushing Oauth2 for both SMTP and IMAP for a really good reason 
> after all.

Ugh.
Why should I need to use a program registered to the service provider
in order to read my email? (Or in my case, register myself as a
developer with Microsoft in order to allow me and my colleagues to
read our own mail.)

In what way is it easier to revoke an OAuth2 token than it is to
change a password? Most people have no clue about how OAuth2 works.
They just know that it's something that gets in the way of working
practices they've been using for 40 years.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Compromised email account trends

2023-02-22 Thread Sebastian Nielsen via mailop

Problem with OAuth2 is that many commercial mail clients only support it for a 
select number of big providers thus you have 2 choices, either implement 
geo-restriction, or have a 2FA auth portal where you authorize IPs to access 
your account.
 Originalmeddelande Från: Taavi Eomäe via mailop 
 Datum: 2023-02-22  19:42  (GMT+01:00) Till: 
mailop@mailop.org Ämne: Re: [mailop] Compromised email account trends 
___mailop mailing 
listmailop@mailop.orghttps://list.mailop.org/listinfo/mailop___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Compromised email account trends

2023-02-22 Thread Taavi Eomäe via mailop


This discussion is getting awfully close to reinventing OAuth2.

It's quite clear by now that long-lived tokens that are nearly 
impossible to properly revoke just don't work well in any human-operated 
contexts.


Hopefully we'll see an increase in the adoption of OAuth2 instead of 
rather crude ways of mitigating only half of the issue. Large players 
started pushing Oauth2 for both SMTP and IMAP for a really good reason 
after all.




On 22/02/2023 13:32, Jaroslaw Rafa via mailop wrote:

Dnia 22.02.2023 o godz. 01:51:41 Sebastian Nielsen via mailop pisze:

If you run a hosting service available internationally, do
this:Use a IP to Country service, to get their country.Append country to
password at both creation, change and login time.For example, if my
password is Password123, the password hash in database would be
hash(Password123-Sweden)When trying to login, if I login from sweden, it
would work wonderfully.But if I try to login from Germany, the password
hash would become hash(Password123-Germany) which doesn't match
hash(Password123-Sweden).This is a great way to IP restrict a account so
it only works from the country it was created/bought from.

With this approach, you must *very explicitly* warn your users that their
accounts will work only within the same country. Otherwise, users who are
travelling to another country and expect to be able to access their e-mail
accounts there, might be *very* disappointed. And if someone eg. loses a
big contract due to not being able to access e-mail, you might probably get
sued.

I have also one more idea. Remember the old "POP-before-SMTP" approach from
the times there was no SMTP AUTH yet? I have observed that the
password-cracking bots are heavily attacking submission services, while
relatively very rarely trying to login to IMAP service. On the other hand,
any regular email client first does IMAP login to get the mailbox index, and
then after the user tries to send a message, authenticates to submission
service. So one might simply reject *any* password on submission service, if
there is no recent successful IMAP login to the same account from the same
IP address.


smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Compromised email account trends

2023-02-22 Thread Slavko via mailop

Dňa 22. februára 2023 14:08:25 UTC používateľ Giovanni Bechis via mailop 
 napísal:

>you should also consider then geolocalization is not perfect and that there
>might be some FP/FN.

Yes, recent days i live in Poland, at least by Maxmind's
GeoIP2Lite Country DB :-)

regards


-- 
Slavko
https://www.slavino.sk/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Compromised email account trends

2023-02-22 Thread Andrew C Aitchison via mailop



On 2/22/23 12:32, Jaroslaw Rafa via mailop wrote:

I have also one more idea. Remember the old "POP-before-SMTP"
approach from the times there was no SMTP AUTH yet? I have observed
that the password-cracking bots are heavily attacking submission
services, while relatively very rarely trying to login to IMAP
service. On the other hand, any regular email client first does
IMAP login to get the mailbox index, and then after the user tries
to send a message, authenticates to submission service. So one
might simply reject *any* password on submission service, if there
is no recent successful IMAP login to the same account from the
same IP address.


Nice idea.

I would want to check that it works for users like me who
download messages to a local machine (eg with fetchmail).
We might be more likely to write before reading.

Do confirm that the submission port remains open to machine/user pairs
as long as an IMAP connection is using IDLE.

On Wed, 22 Feb 2023, Giovanni Bechis via mailop wrote:

this would not work for me, on my servers ~6% of imap logins are
from bots.


*Successful* IMAP logins ?

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Compromised email account trends

2023-02-22 Thread Gellner, Oliver via mailop

On 2023-02-22 15:08, Giovanni Bechis via mailop wrote:

>> I have also one more idea. Remember the old "POP-before-SMTP" approach
>> from the times there was no SMTP AUTH yet? I have observed that the
>> password-cracking bots are heavily attacking submission services,
>> while relatively very rarely trying to login to IMAP service. On the
>> other hand, any regular email client first does IMAP login to get the
>> mailbox index, and then after the user tries to send a message,
>> authenticates to submission service. So one might simply reject *any*
>> password on submission service, if there is no recent successful IMAP
>> login to the same account from the same IP address.

> this would not work for me, on my servers ~6% of imap logins are from bots.

Also you have to consider CGNAT scenarios and other setups where the egress IP 
address of a user might change, which would cause intermittent, unexplainable 
breaks when trying to send emails.

--
BR Oliver

dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.

smime.p7s
Description: S/MIME cryptographic signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Compromised email account trends

2023-02-22 Thread Giovanni Bechis via mailop


On 2/22/23 12:32, Jaroslaw Rafa via mailop wrote:

Dnia 22.02.2023 o godz. 01:51:41 Sebastian Nielsen via mailop pisze:

If you run a hosting service available internationally, do
this:Use a IP to Country service, to get their country.Append country to
password at both creation, change and login time.For example, if my
password is Password123, the password hash in database would be
hash(Password123-Sweden)When trying to login, if I login from sweden, it
would work wonderfully.But if I try to login from Germany, the password
hash would become hash(Password123-Germany) which doesn't match
hash(Password123-Sweden).This is a great way to IP restrict a account so
it only works from the country it was created/bought from.


With this approach, you must *very explicitly* warn your users that their
accounts will work only within the same country. Otherwise, users who are
travelling to another country and expect to be able to access their e-mail
accounts there, might be *very* disappointed. And if someone eg. loses a
big contract due to not being able to access e-mail, you might probably get
sued.


you should also consider then geolocalization is not perfect and that there
might be some FP/FN.


I have also one more idea. Remember the old "POP-before-SMTP" approach from
the times there was no SMTP AUTH yet? I have observed that the
password-cracking bots are heavily attacking submission services, while
relatively very rarely trying to login to IMAP service. On the other hand,
any regular email client first does IMAP login to get the mailbox index, and
then after the user tries to send a message, authenticates to submission
service. So one might simply reject *any* password on submission service, if
there is no recent successful IMAP login to the same account from the same
IP address.

this would not work for me, on my servers ~6% of imap logins are from bots.

 Regards
  Giovanni


OpenPGP_signature
Description: OpenPGP digital signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Compromised email account trends

2023-02-22 Thread Jaroslaw Rafa via mailop

Dnia 22.02.2023 o godz. 01:51:41 Sebastian Nielsen via mailop pisze:
> If you run a hosting service available internationally, do
> this:Use a IP to Country service, to get their country.Append country to
> password at both creation, change and login time.For example, if my
> password is Password123, the password hash in database would be
> hash(Password123-Sweden)When trying to login, if I login from sweden, it
> would work wonderfully.But if I try to login from Germany, the password
> hash would become hash(Password123-Germany) which doesn't match
> hash(Password123-Sweden).This is a great way to IP restrict a account so
> it only works from the country it was created/bought from.

With this approach, you must *very explicitly* warn your users that their
accounts will work only within the same country. Otherwise, users who are
travelling to another country and expect to be able to access their e-mail
accounts there, might be *very* disappointed. And if someone eg. loses a
big contract due to not being able to access e-mail, you might probably get
sued.

I have also one more idea. Remember the old "POP-before-SMTP" approach from
the times there was no SMTP AUTH yet? I have observed that the
password-cracking bots are heavily attacking submission services, while
relatively very rarely trying to login to IMAP service. On the other hand,
any regular email client first does IMAP login to get the mailbox index, and
then after the user tries to send a message, authenticates to submission
service. So one might simply reject *any* password on submission service, if
there is no recent successful IMAP login to the same account from the same
IP address.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Compromised email account trends

2023-02-22 Thread Carsten Schiefner via mailop


Sebastian & all -

On 22.02.2023 01:51, Sebastian Nielsen via mailop wrote:
Didn't get steve's mail for some reason (guess it was because i forgot 
to renew exim tls cert, but its renewed now), but replying to it here.


I have also noticed that: this particular email did not pop into my 
inbox either.


After having looked a bit deeper into this, it appears that Steve 
Freegard replied directly and only to Jarland Donnell on 21 Feb, 12:10 
(timezone?).


Jarland Donnell in turn has then replied publicly to the list again on 
21 Feb, 17:04:02 -0600.


That at least is how I would interpret the present/missing) list footers.

So no mails missed! :-)

Cheers,

-C.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Compromised email account trends

2023-02-21 Thread Sebastian Nielsen via mailop

Didn't get steve's mail for some reason (guess it was because i forgot to renew 
exim tls cert, but its renewed now), but replying to it here.Another good way 
to prevent account compromise in the first place, is:1: If your users solely 
are based in a few countries (employees for example), then Geo-IP restrict 
IMAP/POP3/Submission ports in the firewall to those countries.2: Same applies 
if you run a hosting service that are limited to residents in a certain country 
due to some local payment method being used.3: If you run a hosting service 
available internationally, do this:Use a IP to Country service, to get their 
country.Append country to password at both creation, change and login time.For 
example, if my password is Password123, the password hash in database would be 
hash(Password123-Sweden)When trying to login, if I login from sweden, it would 
work wonderfully.But if I try to login from Germany, the password hash would 
become hash(Password123-Germany) which doesn't match 
hash(Password123-Sweden).This is a great way to IP restrict a account so it 
only works from the country it was created/bought from.Note that if I would try 
to login with "Password123-Sweden" from germany, in an attempt to cheat the 
GeoIP the resolved password would become hash(Password123-Sweden-Germany) and 
login would be rejected.4: Best ever: If your email should only be available in 
office or via office VPN, restrict login to office IP or 192.168.*.*By doing 
this, you greatly reduce the attack surface:Hacker bots trying to dictionary 
attack or bruteforce passwords, would in case 3 just miss the correct password, 
as logging on from a incorrect country yields "Incorrect password", thus hacker 
bot would not bother with a VPN.In case 1 and 2, the email service (except for 
SMTP) would not be visible to them, so they wouldn't bother either.In case 4, 
you basically prevent 100% of compromised accounts.In exim, you can restrict 
which hosts are allowed to authenticate by using auth_advertise_hosts.Reducing 
the attack surface means the damage of a compromised account is much less, 
since now a correct username/password isn't enough. now the hacker must be in 
the right location (or use VPN for the right location) too.Best regard, 
Sebastian Nielsen
 Originalmeddelande Från: Jarland Donnell via mailop 
 Datum: 2023-02-22  00:10  (GMT+01:00) Till: 
mailop@mailop.org Ämne: Re: [mailop] Compromised email account trends Great 
post! Got another one for you all today:coteruth5@gmail.comThis one hit one of 
our customers pretty hard (password reuse, virus, bad variables).On 2023-02-21 
12:10, Steve Freegard wrote:> I recently wrote an entire blog post on this 
topic that might be of> interest:> > 
https://abusix.com/resources/blocklists/compromised-account-detection-with-abusix-mail-intelligence-and-postfix/>
 > It's based on Postfix, but adapting this for Exim shouldn't be> difficult.> 
> Kind regards,> Steve.> > On Wed, 8 Feb 2023 at 13:48, Jarland Donnell via 
mailop>  wrote:> >> Hey everyone. I've been thinking about 
how I could add some more>> value>> to this list and there's one thing I've 
been working on for a while>> that>> I think will be really helpful to share.>> 
>> Email accounts get compromised. It happens. Especially when using>> base>> 
standards (IMAP/POP/SMTP) that inherently lack two-factor>> authentication>> 
mechanisms. As I discover ways to identify when accounts have been>> 
compromised, I'd like to share them with you all.>> >> Today I discovered a new 
trend based on an abuse complaint, which>> allowed me to further identify 
several compromised user email>> accounts>> across our platform. I'd like to 
share with you the headers and>> body,>> censored of any customer information, 
that was sent to me in an>> abuse>> complaint (I also removed the recipient 
that actually reported it):>> > 
https://paste.mxrouteapps.com/?862a67d53b18e8df#2k9DaEP1V9pPe6Th5CmeMS4JbyD38ZkTdDoLpYuWEvcT>>
 >> I expect that this bad actor will change their behavior, and I'll of>> >> 
course adjust. However, if you turn your attention to these two>> variables in 
your logs today you will find anyone who has been>> compromised very recently 
by this actor:>> >> 1. Email subject appears blank in logs (ex. T="" in exim 
log)>> 2. The first recipient they send to is jackgrelesh...@gmail.com>> >> If 
you find someone sending email to jackgrelesh...@gmail.com on>> your>> platform 
today, most especially with a blank subject, I will gladly>> take>> the beating 
for you if you suspend the user and find it to be a>> false>> positive. The 
ide

Re: [mailop] Compromised email account trends

2023-02-21 Thread Ted Cooper via mailop

That's exfiltrating the useful information of the compromise without
needing to maintain control of the device, keep records, or have a bot
controller.

On 22/2/23 09:14, Jarland Donnell via mailop wrote:

Forgot to add on to this:

If your SMTP hostnames, as your customers would configure in Outlook, is
a strange and very unlikely thing for them to send in the subject of an
email, you can also catch these even earlier. This is a censored example
of an email subject sent by this virus today:

T="longhorn.mxrouting.net 587 u...@domain.tld password"

It seems to pull hostname, port, user, and pass to combine and make an
email subject. As best I can tell, from Outlook config files.

On 2023-02-21 17:04, jarl...@mxroute.com wrote:

Great post! Got another one for you all today:

coteru...@gmail.com

This one hit one of our customers pretty hard (password reuse, virus,
bad variables).

On 2023-02-21 12:10, Steve Freegard wrote:

I recently wrote an entire blog post on this topic that might be of
interest:

https://abusix.com/resources/blocklists/compromised-account-detection-with-abusix-mail-intelligence-and-postfix/

It's based on Postfix, but adapting this for Exim shouldn't be
difficult.

Kind regards,
Steve.

On Wed, 8 Feb 2023 at 13:48, Jarland Donnell via mailop
wrote:

Hey everyone. I've been thinking about how I could add some more
value
to this list and there's one thing I've been working on for a while
that
I think will be really helpful to share.

Email accounts get compromised. It happens. Especially when using
base
standards (IMAP/POP/SMTP) that inherently lack two-factor
authentication
mechanisms. As I discover ways to identify when accounts have been
compromised, I'd like to share them with you all.

Today I discovered a new trend based on an abuse complaint, which
allowed me to further identify several compromised user email
accounts
across our platform. I'd like to share with you the headers and
body,
censored of any customer information, that was sent to me in an
abuse
complaint (I also removed the recipient that actually reported it):

https://paste.mxrouteapps.com/?862a67d53b18e8df#2k9DaEP1V9pPe6Th5CmeMS4JbyD38ZkTdDoLpYuWEvcT

I expect that this bad actor will change their behavior, and I'll of

course adjust. However, if you turn your attention to these two
variables in your logs today you will find anyone who has been
compromised very recently by this actor:

1. Email subject appears blank in logs (ex. T="" in exim log)
2. The first recipient they send to is jackgrelesh...@gmail.com

If you find someone sending email to jackgrelesh...@gmail.com on
your
platform today, most especially with a blank subject, I will gladly
take
the beating for you if you suspend the user and find it to be a
false
positive. The idea that following these trends could produce a false

positive has, in my case at least, proven to be more of a rough
theory
than a reality.

Some bonus indications of similar but different compromises:

- Any email sent to ollegas2...@gmail.com, glob22aa.fun, or
mx373.com [1]
consistently links to what I believe is a virus that sends out a
user's
email credentials to the bad actor.

Keep up the good fight friends.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Steve Freegard

Senior Product Owner

+44 7740 364348

abusix.com [2]

Book a meeting [3]

[4]

[5]

[6]

[7]

CONFIDENTIALITY This email and any attachments are confidential and
may also be privileged or otherwise protected from disclosure. If you
are not the named recipient, please notify the sender immediately and
do not disclose the contents to another person, use it for any
purpose, or store or copy the information in any medium.

You’ll find further information about privacy here [8].

Links:
--
[1] http://mx373.com
[2]
https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDzZTf64_AIC7pyl-xmo2L5eYJtYu1PnTYrDUUBmQW-VxiqyfDuPS_3WZnIEFz1xocGdBhnxAEyhHhg3_G29KPX5gu0-0JxXoL3Lw4zV1rZI4zA5EgDWnGc90iUX1HRTDIs=
[3]
https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDzdypi6WPqhVkFKkuLiMX0pY_5fawxs7P25-lwfZUyr7w==
[4]
https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDyIo6EwBskR6pg3M12nuwEx_9G03qmurLHy8H_IjsK3cg==
[5]
https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDweOZAf2SFcCyyLHlLyd4j2GB_p_YWWJ_3WJxEqTQND2A==
[6]
https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZ

Re: [mailop] Compromised email account trends

2023-02-21 Thread Jarland Donnell via mailop