Re: [mailop] Abusix Potentially Compromised Account Report

[Jesse Thompson via mailop]

On 5/19/20 5:51 AM, Thomas Walter via mailop wrote:
> On 19.05.20 12:01, Jaroslaw Rafa via mailop wrote:
>> A shared account by itself is a security loophole.
> Why is that? You can perfectly share an account with IMAP4 Access
> Control Lists.
> 
> The issue is not the shared account, the issue is a shared password.
> 

Correct.  Most of our shared mailboxes are indeed accessed via mailbox 
permissions, but some people still choose to set a password on the shared 
account for reasons; sometimes valid, but sometimes misguided.

I guess I was making the logical leap that if the password was in a breach data 
set, then a password associated with that address exists in the wild.  Maybe 
one of the people with access to that account used the address to sign up for a 
3rd party service, and they presumably shared that password with others and 
made it easy to remember.  A typical user may have signed up for multiple 3rd 
party services using the same password.

Hopefully they used a password manager and generated strong unique passwords 
and shared to their colleagues via the password manager's sharing capabilities. 
 No way to really know unless to ask.  Hence why I see value in getting reports 
like what Abusix is providing.

Jesse


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Thomas Walter via mailop]

On 19.05.20 13:11, Andrew C Aitchison via mailop wrote:
> A bug/issue tracking system or othe5r "help desk" tool
> *may* be a better solution here ...

That's a little overkill for boss & secretary environments.

Regards,
Thomas Walter

-- 
Thomas Walter
Datenverarbeitungszentrale

FH Münster
- University of Applied Sciences -
Corrensstr. 25, Raum B 112
48149 Münster

Tel: +49 251 83 64 908
Fax: +49 251 83 64 910
www.fh-muenster.de/dvz/



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Andrew C Aitchison via mailop]

On Tue, 19 May 2020, Thomas Walter via mailop wrote:


On 19.05.20 12:01, Jaroslaw Rafa via mailop wrote:

There are no practical scenarios that justify the existence and use of
shared accounts.
Use a mailing list instead.


And multiply each and every mail to multiple people, making it difficult
to see which has been replied to and not having shared drafts or
templates? No, thanks.


A bug/issue tracking system or othe5r "help desk" tool
*may* be a better solution here ...

--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Thomas Walter via mailop]

Hey Jaroslaw,

On 19.05.20 12:01, Jaroslaw Rafa via mailop wrote:
> A shared account by itself is a security loophole.

Why is that? You can perfectly share an account with IMAP4 Access
Control Lists.

The issue is not the shared account, the issue is a shared password.

> There are no practical scenarios that justify the existence and use of
> shared accounts.
> Use a mailing list instead.

And multiply each and every mail to multiple people, making it difficult
to see which has been replied to and not having shared drafts or
templates? No, thanks.

Regards,
Thomas Walter

-- 
Thomas Walter
Datenverarbeitungszentrale

FH Münster
- University of Applied Sciences -
Corrensstr. 25, Raum B 112
48149 Münster

Tel: +49 251 83 64 908
Fax: +49 251 83 64 910
www.fh-muenster.de/dvz/



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Jaroslaw Rafa via mailop]

Dnia 18.05.2020 o godz. 16:28:47 Jesse Thompson via mailop pisze:
> 
> (actually, this was a shared account, which means that it likely has a
> poor password, even if it isn't what the attacker is using)

A shared account by itself is a security loophole.
There are no practical scenarios that justify the existence and use of
shared accounts.
Use a mailing list instead.
-- 
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://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Jesse Thompson via mailop]

Finally got one!  

I expect these reports to be largely a lagging indicator of 3rd party password 
dumps, reflecting a certain subset of credential stuffing scenarios.  I don't 
think anyone in our organization is comparing all available breached password 
hashes to local hashes, so it's nice to see when attackers are picking them up 
and using them in various fashions that are observable by Abusix.  

So, I appreciate the free service that Abusix is providing, in this regard.

Even if the attacks just involve using our usernames/addresses against a 3rd 
party site, we know that users tend to re-use passwords within and without our 
systems, so it may help identify an inbound attack ahead of time (if it hasn't 
already happened).  Plus, even if the attacks are against a 3rd party, 
shouldn't we care about our users' security with 3rd party services?  
SAML/OAuth isn't ubiquitous enough such that we can stop 3rd party sites from 
letting people sign up and login with email/password.

Our SOC analysts were confused though (for many of the reasons articulated 
here).  I advised them to look at logs to see if there has been any weird login 
activity with the affected account, and I expressed doubt they will find 
anything.  If the analyst thinks that the password might be at risk (actually, 
this was a shared account, which means that it likely has a poor password, even 
if it isn't what the attacker is using) then they might choose to notify the 
account owner(s) to proactively reset it.  

If they think these reports are a waste of time, then they can just filter them 
out.  No harm done.

Frankly, I wish that we received more of these reports.  Because that might 
spur our identity/security team to more proactively compare hashes against 
available breach data sets.  I assume that the reason we don't receive more is 
because most of the effective attacks happen in a way that Abusix can't 
observe.  The only effective solution (to the overall problem) is to disable 
basic authentication on the services we control, but then we lose observability 
for credential stuffing attacks on the ones we don't.

Jesse

On 4/24/20 8:58 AM, Dave Holmes via mailop wrote:
> We are an outbound only ESP so most of the senders are not real addresses, 
> the reply addresses are. 
> 
> I've had to create a filter in my mailbox to send these to trash - pretty 
> annoying.
> 
> 
> 
> On Fri, 24 Apr 2020 at 14:31, micah anderson via mailop  > wrote:
> 
> 
> Just got two more Abusix reports, things have improved, and gotten
> worse:
> 
> 1. I only was notified about one user, and it was an actual legitimate
> user! That is new.
> 
> 2. I got a notification for that same user twice, in two different
> emails... huh?
> 
> 3. The emails were sent as text/html, with no non-HTML version... call
> me mr grumpy sysadminpants, but come on...
> 
> I still don't know what to do with this, so I'm just turning here to
> complain.
> 
> Bill Cole via mailop mailto:mailop@mailop.org>> 
> writes:
> 
> > On 22 Mar 2020, at 10:28, Steve Freegard via mailop wrote:
> >
> >> Abuse reports shouldn't have to be opt-in.
> >
> > True, but these are not abuse reports to an empowered party, but rather
> > to possible victims.
> >
> > It's akin to the FUSSPs that use mail-based challenge/response models or
> > to SMTP callback verification.
> >
> >>
> >> I didn't design this to annoy people,
> >
> > As designed, it will intrinsically annoy people who in no way deserve
> > the annoyance or can benefit from it.
> >
> >> I did it because it's useful for the internet in general
> >
> > It is not. It is a response to an Internet-wide problem, but it is not
> > broadly useful.
> >
> >> because compromised accounts are a huge issue,
> >
> > Yes, they are. This particular response does not generally improve mail
> > system operators' capacity to mitigate that issue. The core reason that
> > compromised accounts have increased as a problem is that users have
> > gotten used to using the same email address and password everywhere  for
> > authentication. This response does not address that in any way or help
> > anyone receiving reports address it.
> >
> >> and one that causes issues for blacklist providers like us (e.g. if
> >> the compromised accounts are on unblockable IPs, then we have less
> >> ability to stop them), so this was more about providing data that
> >> previously wasn't available *for free* to help the community in
> >> general.
> >
> > My mail logs and sometimes mailboxes are filled with essentially the
> > same data for free in the form of backscatter. I can get a pretty good
> > list of what email addresses in my domains are being shopped around at
> > HIBP. I've mostly eliminated even logging of credential-stuffers by
>

Re: [mailop] Abusix Potentially Compromised Account Report

[Dave Holmes via mailop]

We are an outbound only ESP so most of the senders are not real addresses,
the reply addresses are.

I've had to create a filter in my mailbox to send these to trash - pretty
annoying.



On Fri, 24 Apr 2020 at 14:31, micah anderson via mailop 
wrote:

>
> Just got two more Abusix reports, things have improved, and gotten
> worse:
>
> 1. I only was notified about one user, and it was an actual legitimate
> user! That is new.
>
> 2. I got a notification for that same user twice, in two different
> emails... huh?
>
> 3. The emails were sent as text/html, with no non-HTML version... call
> me mr grumpy sysadminpants, but come on...
>
> I still don't know what to do with this, so I'm just turning here to
> complain.
>
> Bill Cole via mailop  writes:
>
> > On 22 Mar 2020, at 10:28, Steve Freegard via mailop wrote:
> >
> >> Abuse reports shouldn't have to be opt-in.
> >
> > True, but these are not abuse reports to an empowered party, but rather
> > to possible victims.
> >
> > It's akin to the FUSSPs that use mail-based challenge/response models or
> > to SMTP callback verification.
> >
> >>
> >> I didn't design this to annoy people,
> >
> > As designed, it will intrinsically annoy people who in no way deserve
> > the annoyance or can benefit from it.
> >
> >> I did it because it's useful for the internet in general
> >
> > It is not. It is a response to an Internet-wide problem, but it is not
> > broadly useful.
> >
> >> because compromised accounts are a huge issue,
> >
> > Yes, they are. This particular response does not generally improve mail
> > system operators' capacity to mitigate that issue. The core reason that
> > compromised accounts have increased as a problem is that users have
> > gotten used to using the same email address and password everywhere  for
> > authentication. This response does not address that in any way or help
> > anyone receiving reports address it.
> >
> >> and one that causes issues for blacklist providers like us (e.g. if
> >> the compromised accounts are on unblockable IPs, then we have less
> >> ability to stop them), so this was more about providing data that
> >> previously wasn't available *for free* to help the community in
> >> general.
> >
> > My mail logs and sometimes mailboxes are filled with essentially the
> > same data for free in the form of backscatter. I can get a pretty good
> > list of what email addresses in my domains are being shopped around at
> > HIBP. I've mostly eliminated even logging of credential-stuffers by
> > dropping their crap at the border, a thing that many small mail system
> > operators can do. Even the data on such activity I can look at is mostly
> > useless to me because it is overwhelmingly for single-purpose addresses,
> > role accounts, or other sorts of non-authenticating aliases.
> >
> > I really don't need or want more unrequested "free information
> > customized for your needs" by people who clearly do not understand my
> > needs and whom I am reluctant to generally shun. This should be like a
> > FBL: a great idea for people who can actually use it, but not something
> > you want to impose on everyone who might be able to use it.
> >
> > --
> > Bill Cole
> > b...@scconsult.com or billc...@apache.org
> > (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
> > Not For Hire (currently)
> >
> > ___
> > mailop mailing list
> > mailop@mailop.org
> > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
> --
> micah
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>


-- 

[image: Instiller Logo] 
Dave Holmes
Technical Director

d...@instiller.co.uk
T 0333 939 0013  |  M 07966 013 309
1 Park Farm Barns | Packington Lane | Stonebridge | CV7 7TL


Instiller is a trademark of Instiller Limited, registered in England
5053657.

This email contains proprietary information, some of which may be legally
privileged. It is for the intended recipient only.
If an addressing or transmission in error has misdirected this email,
please notify the author by replying to this email.
If you are not the intended recipient, you must not use, disclose,
distribute, copy, print or rely on this email.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[micah anderson via mailop]

Just got two more Abusix reports, things have improved, and gotten
worse:

1. I only was notified about one user, and it was an actual legitimate
user! That is new.

2. I got a notification for that same user twice, in two different
emails... huh?

3. The emails were sent as text/html, with no non-HTML version... call
me mr grumpy sysadminpants, but come on...

I still don't know what to do with this, so I'm just turning here to
complain.

Bill Cole via mailop  writes:

> On 22 Mar 2020, at 10:28, Steve Freegard via mailop wrote:
>
>> Abuse reports shouldn't have to be opt-in.
>
> True, but these are not abuse reports to an empowered party, but rather 
> to possible victims.
>
> It's akin to the FUSSPs that use mail-based challenge/response models or 
> to SMTP callback verification.
>
>>
>> I didn't design this to annoy people,
>
> As designed, it will intrinsically annoy people who in no way deserve 
> the annoyance or can benefit from it.
>
>> I did it because it's useful for the internet in general
>
> It is not. It is a response to an Internet-wide problem, but it is not 
> broadly useful.
>
>> because compromised accounts are a huge issue,
>
> Yes, they are. This particular response does not generally improve mail 
> system operators' capacity to mitigate that issue. The core reason that 
> compromised accounts have increased as a problem is that users have 
> gotten used to using the same email address and password everywhere  for 
> authentication. This response does not address that in any way or help 
> anyone receiving reports address it.
>
>> and one that causes issues for blacklist providers like us (e.g. if 
>> the compromised accounts are on unblockable IPs, then we have less 
>> ability to stop them), so this was more about providing data that 
>> previously wasn't available *for free* to help the community in 
>> general.
>
> My mail logs and sometimes mailboxes are filled with essentially the 
> same data for free in the form of backscatter. I can get a pretty good 
> list of what email addresses in my domains are being shopped around at 
> HIBP. I've mostly eliminated even logging of credential-stuffers by 
> dropping their crap at the border, a thing that many small mail system 
> operators can do. Even the data on such activity I can look at is mostly 
> useless to me because it is overwhelmingly for single-purpose addresses, 
> role accounts, or other sorts of non-authenticating aliases.
>
> I really don't need or want more unrequested "free information 
> customized for your needs" by people who clearly do not understand my 
> needs and whom I am reluctant to generally shun. This should be like a 
> FBL: a great idea for people who can actually use it, but not something 
> you want to impose on everyone who might be able to use it.
>
> -- 
> Bill Cole
> b...@scconsult.com or billc...@apache.org
> (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
> Not For Hire (currently)
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
-- 
micah

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Francois Petillon via mailop]

On 3/24/20 11:36 AM, Steve Freegard via mailop wrote:
> I also found that I wasn't discarding some drive-by stuff which is more akin 
> to
> what you were talking about so I've also corrected that which will further
> reduce the noise, raise the quality and reduce the number of daily reports 
> being
> sent.

Hi,

I have just checked the latest Abusix report I have received for free.fr
accounts. Out of the 56 reported accounts, I have :
- 8 accounts that have never existed (14.3%)
- 2 accounts that do not seem to have ever used the hashed password. These
acccounts have never been detected as compromised on my side.
- 3 accounts that seem to have used the hashed password but changed it. These
accounts have never been detected as compromised on my side.

All other accounts (76.8%) have been blocked between 2015 and late 2018 (either
their passwords their published in combo lists, or their accounts were detected
as compromised) and all the hashed passwords were in my "compromised passwords"
list.

From my point of view, there has been a great improvement in your reports. But,
AFAIAC, there are quite useless as (1) the data is quite old (even if the
compromised passwords are still checked) and  as (2) I am collecting the
compromised passwords to be sure that a user will never reuse a password
slightly modified.

François

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Blake Hudson via mailop]

On 3/24/2020 11:19 AM, Steve Freegard via mailop wrote:

Hi Micah,

On 24/03/2020 16:10, micah anderson wrote:


FWIW, we got a couple of these Abusix reports, checked them out and
determined they were all false positives. Every single one of them was
either an account that hasn't existed for years, or wasn't even a valid
account (like mailing list -subscribe addresses).

I appreciate what you guys are trying to do, but after making us jump
for a bunch of false positives, this makes us consider this a 'cry wolf'
service that we'll probably ignore very quickly. I'm sure you have
actual legit data in there and if you had sent me things that were
legit, it would have been helpful to know about it.


Thanks for the feedback, as I posted earlier - I found some data that 
wasn't being excluded that should have been, so this made the initial 
reports noisier than they normally would be.


Hopefully if you get any more, they'll be more useful.


Just to add another point of perspective, we received our second report 
today:

"cou...@x.com","b7c99","77.120.228.177",1585784605,"2020-04-01T23:43:25.000Z"

This is a domain we provide MX for, but this is not a valid user. This 
has been the case for most of the information that has been reported. As 
others have stated, we have no relation to the IP address in the report 
- I'm not sure why it's included or for who's benefit. Rather than 
sending folks a list of email addresses that never existed on their 
systems, perhaps it would be reasonable to try and vet these usernames 
to see if they currently exist. Or just let folks go to the Abuseix 
website themselves and perform a search of their domains or IP space. I 
assume your intent was noble, but in their current form these reports 
have been unhelpful and unsolicited.


Thank you for your time,
--B

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Al Iverson via mailop]

I got my first "Abusix Potentially Compromised Account Report" today,
I'm so lucky.

It is useless. It's warning us about activity relating to domains that
don't have users. Activity not originating from or directly targeting
anything hosted by us.

No thanks? We want only reports of actual abuse, not maybes based on
when you see somebody on the other side of the earth trying to forge
my domain name. This is only slightly less annoying than the
backscatter that we used to see when people would forge our domain
name in spam back before DMARC and email authentication.

Find a way to add this new data to some opt-in style report like how
DMARC reports work, if you want. But shotgunning it without consent
and understanding is bad form. It's not like a 1:1 email spam report
-- effectively the only type of commonly welcomed unsolicited
complaint report. And it's not even really unsolicited, in that it's a
response to activity seen originating from my network. This Abusix
report fails those measures. You might as well be sending me emails
telling me that I'm hacking your port 80.

Regards,
Al Iverson


-- 
al iverson // wombatmail // chicago
dns tools are cool! https://xnnd.com

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Atro Tossavainen via mailop]

> Once-only invitations to opt-in sound cool.

Not to me - we tell marketers they can't ask permission by spamming,
so I don't think anybody else should get a free pass either.

IT. DOES. NOT. SCALE. Nobody gives a flying flamingo about who the
sender is or what the purpose of the messaging is. IT. DOES. NOT. SCALE.

> 100% agreed, albeit rfc2142 addresses are assumed to be implicitly opted-in 
> for
> the corresponding kind of messages.

If there was a point, but since the data itself is diiba daaba liiba laaba,
I'd say it's on a level with the work of the late Marc Perkel, may he rest
in peace. CHALLENGE/RESPONSE anyone?

-- 
Atro Tossavainen, Chairman of the Board
Infinite Mho Oy, Helsinki, Finland
tel. +358-44-5000 600, http://www.infinitemho.fi/

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Alessandro Vesely via mailop]

On Wed 25/Mar/2020 11:36:52 +0100 Laura Atkins via mailop wrote:
>> On 25 Mar 2020, at 10:00, Alessandro Vesely via mailop wrote:
>>
>> For a comparison, how'd you rate the signal to noise ratio of (accumulated)
>> DMARC aggregate reports?
> 
> I don’t think there’s a valid comparison as DMARC reports are opt-in and the
> folks who are opting into them understand what they’re getting into. 


Indeed, I asked because there have been multiple references to DMARC opt-in in
this thread.


> The real solution here is to do the work and make these reports opt-in. You 
> can
> even do it as 1 or two reports to postmaster and offer the option to opt-in to
> future reports. it also allows recipients to designate a different / more
> appropriate email address to handle the reports. 


DMARC is innovative as it allows people to opt-in with a specific address,
piping into a bot which understands a specific data format.

Once-only invitations to opt-in sound cool.

If recipients were willing to automatically check passwords hashes and get
warned only on matches, it could be a useful tool.  For even more useless
mails, I'd mention positive ("total-failure-session-count":0) tlsrpt reports.


> Just randomly sending folks bulk, automated mail will always be a problem. It
> seems silly to argue that unsolicited bulk email is a good idea just because
> some people like it. 


100% agreed, albeit rfc2142 addresses are assumed to be implicitly opted-in for
the corresponding kind of messages.


Best
Ale
-- 





















___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Atro Tossavainen via mailop]

> Uh, well, aren't you curious about how bots harvest that data?

I am indeed not.

Using leaked credentials from Adobe, Dropbox, LinkedIn, or any other
widely available leak that has email addresses and passwords is quite
the sufficient explanation for me. There may be others, but this is
large enough to make me totally not interested in the rest...

On the other hand, we have these "reports" in typotraps that have never
existed as real services. So maybe the stuff that isn't pulled out of
leaks could be even better - 100% made up, "credentials" in domains that
never existed in a way that they could have had any credentials in them.

> Hardly actionable, but it could help in building a picture of how wide and
> interconnected the bot networks are, couldn't it?

I'll quite happily leave that job to Chris. The amount of data he has
is perhaps a few bazillion times more than what we get, and he's got
a specific interest in the topic.  

> For a comparison, how'd you rate the signal to noise ratio of (accumulated)
> DMARC aggregate reports?

Without going into the reports themselves, let us just remember that you
don't get any if you haven't asked for them, which makes it a question
of definition rather than content analysis as far as I am concerned.

-- 
Atro Tossavainen, Chairman of the Board
Infinite Mho Oy, Helsinki, Finland
tel. +358-44-5000 600, http://www.infinitemho.fi/

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Laura Atkins via mailop]

> On 25 Mar 2020, at 10:00, Alessandro Vesely via mailop  
> wrote:
> 
> For a comparison, how'd you rate the signal to noise ratio of (accumulated)
> DMARC aggregate reports?

I don’t think there’s a valid comparison as DMARC reports are opt-in and the 
folks who are opting into them understand what they’re getting into. 

This argument reminds me of the widespread relay testing from 20 years ago that 
ended up with double bounce mails landing in postmaster mailboxes. A lot of 
folks managing those mailboxes were legitimately annoyed at the relay testing 
sites that would probe their networks and, when their networks didn’t relay, 
drop unwanted and unsolicited email into postmaster@ in the form of double 
bounces. 

Deploying any service that ends up with folks receiving high levels of emails 
that they did not ask for is problematic, even when some people find those 
reports useful. 

The real solution here is to do the work and make these reports opt-in. You can 
even do it as 1 or two reports to postmaster and offer the option to opt-in to 
future reports. it also allows recipients to designate a different / more 
appropriate email address to handle the reports. 

Just randomly sending folks bulk, automated mail will always be a problem. It 
seems silly to argue that unsolicited bulk email is a good idea just because 
some people like it. 

laura 

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
la...@wordtothewise.com
(650) 437-0741  

Email Delivery Blog: https://wordtothewise.com/blog 







___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Alessandro Vesely via mailop]

On Tue 24/Mar/2020 17:22:14 +0100 Atro Tossavainen via mailop wrote:
> On Tue, Mar 24, 2020 at 10:58:14AM -0500, Al Iverson via mailop wrote:
>> I'm not understanding how this intersects with spamtraps. What does
>> this alert actually notify a network owner of?
>> Failed SMTP auth attempt from my IP space?
>> Or a failed SMTP auth attempt from someplace else TO my IP space?
>> Or door #3?
> 
> Failed SMTP auth attempt to somewhere controlled by Abusix, using
> credentials "apparently at" domains that are not served by any
> reasonable stretch of imagination by the Abusix hosts involved.
> 
> Door #3. It has nothing to do with your IP space, and it only has
> to do with bots pulling domains that belong to you to use here
> out of their ...I meant to say thin air, of course.


Ah, thank you so much Atro, now I'm starting to understand something.


> To me, that constitutes pure noise with no signal.


Uh, well, aren't you curious about how bots harvest that data?

Hardly actionable, but it could help in building a picture of how wide and
interconnected the bot networks are, couldn't it?

For a comparison, how'd you rate the signal to noise ratio of (accumulated)
DMARC aggregate reports?


Best
Ale
-- 















___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Graeme Fowler via mailop]

On 24 Mar 2020, at 16:52, Michael Peddemors via mailop  
wrote:
> Like others on the list pointed out, if you send 'noise' then people will 
> simply 'tune out' to your reports. While I commend you for looking at ways to 
> help address the problem, you might want to have a smaller set of more 
> accurate reports, and then widen it bit by bit, rather than the other way 
> around.

If I might add an extra bit of weight to the "noise" point: albeit operating at 
a vastly smaller scale than many here, the Abuseix report we got at $workplace 
tied up a member of the security team, 3 members of staff (whose accounts had 
not and never have been compromised but were incovenienced nonetheless) and 
colleagues on the service desk for an appreciable amount of time yesterday.

This at a point where world events dictate that we simply don't have that time, 
*especially* our first line guys.

I'm still not quite sure I understand the methodology myself.

Graeme (wearing work hat)
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Rob McEwen via mailop]

On 3/24/2020 6:36 AM, Steve Freegard via mailop wrote:

Rob should have done the same



Steve,

The last time I even mentioned "invaluement" at MailOp - and it was an 
on-topic post - I got very harshly criticized for allegedly being too 
promotional and spammy. Someone had complained about a spam not being 
blocked by any of the blacklists, and I mentioned that invaluement had 
the particular domain or IP already-blacklisted for a while at that 
point. Maybe I was being too self-promoting? But I felt like the 
take-town was rather unprofessional and nasty way over the top. I 
was disappointed that there was no pushback on that. I can take 
criticism, but it ought to be professional and not mean-spirited. In 
contrast, the criticism of your posts in this thread has been very very 
tame by comparison. But hopefully this will explain for you how/why I 
trying hard to NOT mention "invaluement" unless absolutely necessary. So 
hopefully you'll understand now why I didn't do that "disclaimer" that 
you think I should have done.


I guess people don't take too kindly if/when anti-spam blacklists 
services engage in even the slightest spammy behavior? For this reason, 
I wouldn't ever even consider doing anything that involves sending 
unsolicited bulk email, even if there was an altruistic angle to it. But 
maybe I'm too cautious?


--
Rob McEwen, CEO of invaluement

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Michael Peddemors via mailop]

On 2020-03-24 9:35 a.m., micah anderson via mailop wrote:

Steve Freegard via mailop  writes:


I included the partial SHA-1 to be compatible with automation and
tooling around the HaveIBeenPwned API - see
https://haveibeenpwned.com/API/v3#PwnedPasswords


I understand that desire, but I wish the HaveIBeenPwned things were
better. As a provider, even with their API, its basically useless for us
to actually consume in a way that makes sense.



While 'haveIbeenpwned' is an interesting piece of data for researchers, 
having an email address password combination in there does NOT 
necessarily mean the account has been compromised either, or more to the 
point, still compromised.


There are many other tools available to email operators to detect email 
compromises (rate limiters, outbound filtering, authentication source 
verification and ACL's etc), and of course implementing multi-factor 
authentication, can also address re-used passwords.


Like others on the list pointed out, if you send 'noise' then people 
will simply 'tune out' to your reports.  While I commend you for looking 
at ways to help address the problem, you might want to have a smaller 
set of more accurate reports, and then widen it bit by bit, rather than 
the other way around.





--
"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://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Chris via mailop]

On 2020-03-24 11:48, Steve Freegard via mailop wrote:


thraxisp@:16472



Sure - that's a totally useless password and I'm happy to report I 
haven't seen that particular username, but without an IP - it's a bit 
meaningless as I can't tell you if we're seeing traffic on it or not.


I checked.  You aren't.

However I could go and pull a bunch of other IPs from this collection 
method that the CBL also does not see - I'm just trying to convey that 
you're making a lot of (incorrect) assumptions about the usefulness of 
data that, based upon evidence, you don't appear to have.


You're making an assumption again.

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Al Iverson via mailop]

On Tue, Mar 24, 2020 at 11:27 AM Atro Tossavainen via mailop
 wrote:
>
> On Tue, Mar 24, 2020 at 10:58:14AM -0500, Al Iverson via mailop wrote:
> > I'm not understanding how this intersects with spamtraps. What does
> > this alert actually notify a network owner of?
> > Failed SMTP auth attempt from my IP space?
> > Or a failed SMTP auth attempt from someplace else TO my IP space?
> > Or door #3?
>
> Failed SMTP auth attempt to somewhere controlled by Abusix, using
> credentials "apparently at" domains that are not served by any
> reasonable stretch of imagination by the Abusix hosts involved.
>
> Door #3. It has nothing to do with your IP space, and it only has
> to do with bots pulling domains that belong to you to use here
> out of their ...I meant to say thin air, of course.
>
> To me, that constitutes pure noise with no signal.

Somebody forged your domain in SMTP auth/relay attempts over here? Oh
boy, I'd say that's basically a new form of blowback.

Ask Atro and Chris-- I don't always agree with them and I'm not one to
jump on a bandwagon-- but when they both tell you what you're doing is
clown shoes, you really ought to put it on pause and look down and see
what you've got on your feet.

In this case, they are 100% right. These are not useful notifications.

If somebody finds these valuable, develop an opt-in mechanism for
sending them. Like for DMARC reports.

Regards,
Al Iverson


-- 
al iverson // wombatmail // chicago
dns tools are cool! https://xnnd.com

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[micah anderson via mailop]

Steve Freegard via mailop  writes:

> I included the partial SHA-1 to be compatible with automation and 
> tooling around the HaveIBeenPwned API - see 
> https://haveibeenpwned.com/API/v3#PwnedPasswords

I understand that desire, but I wish the HaveIBeenPwned things were
better. As a provider, even with their API, its basically useless for us
to actually consume in a way that makes sense.

-- 
micah

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Steve Freegard via mailop]

Hi Al,

On 24/03/2020 15:58, Al Iverson via mailop wrote:

I'm not understanding how this intersects with spamtraps. What does
this alert actually notify a network owner of?
Failed SMTP auth attempt from my IP space?
Or a failed SMTP auth attempt from someplace else TO my IP space?
Or door #3?



In this case it's door #3 ;-)

We're reporting usernames and partial password hashes to the domain 
owner (and Abuse Contact for the MX IPs) of accounts that we've seen 
authenticating to one of our more exotic trap types which sees stuff 
that is different to the regular AUTH junk normally observed on a 
regular spam trap.


It's an attempt to help admins/postmasters spot compromised accounts 
with data that they wouldn't normally be able to see.


It came about as when I started poking at this data as a Xmas project, 
it unearthed a compromise at a couple of ISPs (~50-100 accounts) which 
was verified and quickly stopped by both.


So I worked on getting rid of as much chaff as I possibly could, 
basically by only ever reporting accounts that we've not seen in the 
last 31 days (e.g. long enough to dial down the repetition or stuff that 
is endlessly retried, whilst still having being able to spot a 
re-compromised account) and sending out to the internet daily.


Compromised accounts are one of my biggest bugbears as a BL operator, I 
hate having to blacklist IPs for account compromises that don't get 
cleaned up for days, and it was my hope that this will help that situation.


Kind regards,
Steve.

--
Steve Freegard
Senior Product Owner
Abusix Intelligence

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Atro Tossavainen via mailop]

On Tue, Mar 24, 2020 at 10:58:14AM -0500, Al Iverson via mailop wrote:
> I'm not understanding how this intersects with spamtraps. What does
> this alert actually notify a network owner of?
> Failed SMTP auth attempt from my IP space?
> Or a failed SMTP auth attempt from someplace else TO my IP space?
> Or door #3?

Failed SMTP auth attempt to somewhere controlled by Abusix, using
credentials "apparently at" domains that are not served by any
reasonable stretch of imagination by the Abusix hosts involved.

Door #3. It has nothing to do with your IP space, and it only has
to do with bots pulling domains that belong to you to use here
out of their ...I meant to say thin air, of course.

To me, that constitutes pure noise with no signal.


--- begin forwarded report ---
From: Abusix 
Subject: Abusix Potentially Compromised Account Report
To: postmaster@domain

Hello,

Over the last 24 hour period our traps have detected SO AND SO MANY potentially 
compromised accounts on your domain.

Attached is a CSV file containing the username, first five characters of the 
SHA-1 hash calculated from the password that was used,  the IP address that 
attempted the login and the UNIX timestamp of the attempt.

We only send notices for usernames that we have not seen previously, this is to 
reduce the amount of unnecessary noise and to hopefully increase  the 
usefulness of these reports to you.

This data is collected by observing hosts abusing our traps and sending SMTP 
AUTH credentials to external domains (like yours).  Note that we do not store 
usernames and passwords, just the usernames.

We have also sent a copy of this report to the Abuse Contact(s) determined by 
looking up the IP addresses that your MX record(s) point to in our Abuse 
Contact DB, this is under the presumption that whatever service handles the 
inbound mail for your domain probably also handles the outbound mail, as a 
compromised account will potentially impact them too.

This is an experimental free service powered by Abusix Mail Intelligence and 
may be revised or teminated at any time.   We're committed to help prevent and 
clean-up abuse on the internet and we're always interested in hearing your 
feeback on this service.

You can find more details and frequently asked questions about our reports here.

This data is provided under this license and is generated daily at midnight GMT.

If you'd prefer not to receive these reports, you can opt-out here.

--- end forwarded report ---

The format of the attached CSV file is as follows:

"username","pw_sha1","source_ip","timestamp","human_date"
"blah@domain","0","127.0.0.1",1584xx,"2020-03-xxThh:mm:ss.000Z" 


> 
> Regards,
> Al Iverson
> 
> -- 
> al iverson // wombatmail // chicago
> dns tools are cool! https://xnnd.com
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

-- 
Atro Tossavainen, Chairman of the Board
Infinite Mho Oy, Helsinki, Finland
tel. +358-44-5000 600, http://www.infinitemho.fi/

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Steve Freegard via mailop]

Hi Micah,

On 24/03/2020 16:10, micah anderson wrote:


FWIW, we got a couple of these Abusix reports, checked them out and
determined they were all false positives. Every single one of them was
either an account that hasn't existed for years, or wasn't even a valid
account (like mailing list -subscribe addresses).

I appreciate what you guys are trying to do, but after making us jump
for a bunch of false positives, this makes us consider this a 'cry wolf'
service that we'll probably ignore very quickly. I'm sure you have
actual legit data in there and if you had sent me things that were
legit, it would have been helpful to know about it.


Thanks for the feedback, as I posted earlier - I found some data that 
wasn't being excluded that should have been, so this made the initial 
reports noisier than they normally would be.


Hopefully if you get any more, they'll be more useful.

As we can't actively test something like this, it's impossible to know 
which aren't legit - my hope was that people would write some automation 
to do this stuff and raise an alarm when something is found.



Fortunately, we
aren't using SHA1 hashing for our passwords, as this is known to be
broken, so those hashes were also a bit pointless for us. Considering
the different types of password hashing that are available, and salts,
this is kind of useless.


I included the partial SHA-1 to be compatible with automation and 
tooling around the HaveIBeenPwned API - see 
https://haveibeenpwned.com/API/v3#PwnedPasswords


Kind regards,
Steve.

--
Steve Freegard
Senior Product Owner
Abusix Intelligence

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[micah anderson via mailop]

Steve Freegard via mailop  writes:

> On 24/03/2020 15:10, Chris via mailop wrote:
>> On 2020-03-24 06:36, Steve Freegard via mailop wrote:
>>
>>> I have great respect for you, but I didn't spend a considerable 
>>> amount of development time without actually being absolutely certain 
>>> about what I was doing.  Your experience is not relevant because you 
>>> do not have experience with equivalent traps to these - I know this 
>>> for certain because I would have come across them, this also proves it:
>>>
>>> { auth_method: 'PLAIN',
>>> auth_password: 'g3tt0ugh!',
>>> auth_username: '',
>>> source_ip: '185.64.105.8'
>>> }
>>
>> With respect, Steve, you have no idea what we're doing with traps.
>
> That's mostly true, but for this particular scenario of where I am 
> getting this AUTH data from - I would absolutely know because it would 
> be almost statistically impossible for me not to spot this at the scale 
> we both handle data.   For example - I know that IBM X-Force is also 
> doing something similar to me because I've observed them doing it as 
> this is something that I regularly check.

FWIW, we got a couple of these Abusix reports, checked them out and
determined they were all false positives. Every single one of them was
either an account that hasn't existed for years, or wasn't even a valid
account (like mailing list -subscribe addresses).

I appreciate what you guys are trying to do, but after making us jump
for a bunch of false positives, this makes us consider this a 'cry wolf'
service that we'll probably ignore very quickly. I'm sure you have
actual legit data in there and if you had sent me things that were
legit, it would have been helpful to know about it. Fortunately, we
aren't using SHA1 hashing for our passwords, as this is known to be
broken, so those hashes were also a bit pointless for us. Considering
the different types of password hashing that are available, and salts,
this is kind of useless.


-- 
micah

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Steve Freegard via mailop]

On 24/03/2020 15:10, Chris via mailop wrote:

On 2020-03-24 06:36, Steve Freegard via mailop wrote:

I have great respect for you, but I didn't spend a considerable 
amount of development time without actually being absolutely certain 
about what I was doing.  Your experience is not relevant because you 
do not have experience with equivalent traps to these - I know this 
for certain because I would have come across them, this also proves it:


{ auth_method: 'PLAIN',
auth_password: 'g3tt0ugh!',
auth_username: '',
source_ip: '185.64.105.8'
}


With respect, Steve, you have no idea what we're doing with traps.


That's mostly true, but for this particular scenario of where I am 
getting this AUTH data from - I would absolutely know because it would 
be almost statistically impossible for me not to spot this at the scale 
we both handle data.   For example - I know that IBM X-Force is also 
doing something similar to me because I've observed them doing it as 
this is something that I regularly check.




I fail to see how a single sample proves anything.  If it did, I'd 
disprove your proof with something I just plucked out:


thraxisp@:16472



Sure - that's a totally useless password and I'm happy to report I 
haven't seen that particular username, but without an IP - it's a bit 
meaningless as I can't tell you if we're seeing traffic on it or not.


However I could go and pull a bunch of other IPs from this collection 
method that the CBL also does not see - I'm just trying to convey that 
you're making a lot of (incorrect) assumptions about the usefulness of 
data that, based upon evidence, you don't appear to have.


That's all.

Kind regards,
Steve.

--
Steve Freegard
Senior Product Owner
Abusix Intelligence

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Chris via mailop]

On 2020-03-24 06:36, Steve Freegard via mailop wrote:

I have great respect for you, but I didn't spend a considerable amount 
of development time without actually being absolutely certain about what 
I was doing.  Your experience is not relevant because you do not have 
experience with equivalent traps to these - I know this for certain 
because I would have come across them, this also proves it:


{ auth_method: 'PLAIN',
auth_password: 'g3tt0ugh!',
auth_username: '',
source_ip: '185.64.105.8'
}


With respect, Steve, you have no idea what we're doing with traps.

I fail to see how a single sample proves anything.  If it did, I'd 
disprove your proof with something I just plucked out:


thraxisp@:16472

As to attribution, you're probably right, I should have said something. 
 On the other hand, it should have been pretty obvious in context.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Steve Freegard via mailop]

Chris,

On 22/03/2020 20:41, Chris via mailop wrote:
> On 2020-03-22 16:20, Nick Stallman via mailop wrote:
>> I got one of these the other day and I'm scratching my head about it 
as what's in the report cannot possibly be correct.

>>
>> The report was for a domain we host the website for, but the domain 
has no email at all.
>> The account referenced is also not a valid website login or anything 
else I can think of.

>>
>> It's not terribly useful if I'm going to be getting red herrings 
like that.

>
> It's been my experience that MOST of them are going to be 
red-herrings.  I've seen a whole pile of such forged addresses with 
userids/passwords that I knew were completely impossible.


I have great respect for you, but I didn't spend a considerable amount 
of development time without actually being absolutely certain about what 
I was doing.  Your experience is not relevant because you do not have 
experience with equivalent traps to these - I know this for certain 
because I would have come across them, this also proves it:


{ auth_method: 'PLAIN',
auth_password: 'g3tt0ugh!',
auth_username: '',
source_ip: '185.64.105.8'
}

I just plucked that out of the stream of a newly identified accounts - 
that password looks pretty legitimate to me...  and at the time of 
writing this, that IP wasn't listed on Spamhaus, Invaluement or anywhere 
else...


So I can assure you I examined this in detail and proved the value of it 
by working with several ISPs.


In this thread, we've got one person that found what looked like actual 
compromised accounts and I've had other reports of this off-list, so it 
is helping take down this stuff, and that will increase over time as 
people add automation to this - which is already starting to happen.


>
> Imagine how useful it's going to be if you have a lot of spamtraps.  
I mean, a *LOT* of spamtraps.

>

It's not the size and number of your spamtraps, it's what you do with 
them ;-)


Based on yours, Atro's and Rob's feedback on this - I've spent some time 
coding to exclude all of your traps from the reporting which is live as 
of last night, so you might have gotten one more report, but from 
tonight onward the vast majority will be excluded.


I also found that I wasn't discarding some drive-by stuff which is more 
akin to what you were talking about so I've also corrected that which 
will further reduce the noise, raise the quality and reduce the number 
of daily reports being sent.


We are constantly improving our services for customers and for the 
greater community on a daily basis by challenging the status quo. We 
constantly re-evaluate what we do and how we do it and the wider 
positive feedback makes us believe that we are on the right track.


Lastly - I really appreciated Atro's disclaimer - I think I should point 
out to anyone that doesn't already know that both you and Rob should 
have done the same as you both run competing services.


And that's the last thing I'm going to say on this matter...

Kind regards,
Steve.

--
Steve Freegard
Senior Product Owner
Abusix Intelligence


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Chris via mailop]

On 2020-03-22 20:44, Rob McEwen via mailop wrote:

On 3/22/2020 4:41 PM, Chris via mailop wrote:

It's been my experience that MOST of them are going to be red-herrings



+1

2 days ago, I got one of these for a domain for which I host email. I 
checked the SHA-1 hash against the current password's SHA-1 hash, and it 
didn't match. So it seemed like a complete waste of my time. I suspect 
that the vast majority of such intercepts... are going to be situations 
just like that - old passwords that were already changed years ago. I 
vaguely recall this users' account getting hacked several years ago, and 
the problem being fixed way back then. I don't like my time wasted 
trying to fix already-fixed problems.


Frankly, I think the most likely case is that it was never a valid password.

I once administered a very large domain where *I* managed the password 
database and implemented the pw quality checker.


Most of passwords I saw wouldn't possibly have passed the quality checker.

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Alessandro Vesely via mailop]

On Sun 22/Mar/2020 18:12:57 +0100 Steve Freegard via mailop wrote:
> On 22/03/2020 16:05, Andrew C Aitchison wrote:
>> On Sun, 22 Mar 2020, Steve Freegard via mailop wrote:
>>> I didn't design this to annoy people, I did it because it's useful for the
>>> internet in general because compromised accounts are a huge issue, and one
>>> that causes issues for blacklist providers like us (e.g. if the compromised
>>> accounts are on unblockable IPs, then we have less ability to stop them), so
>>> this was more about providing data that previously wasn't available *for
>>> free* to help the community in general.
>>
>> Is it possible, and/or useful, to reuse the DMARC reporting mechanism ?
>>
> 
> I didn't do this because I figured that postmaster@ was the most appropriate
> place, and because many places will use service like DMARCian, Agari etc. for
> aggregate reports and it would mean that they'd be less likely to be seen if I
> sent them there.


Hm... I skimmed through this thread and didn't get an exact picture of what
data is being reported.  How would it fit in the format specified for aggregate
reports?

The point of DMARC reports is to help domain owners understand who is sending
mail that purports to be from them.  I think reporting abusive spam by
professional identity thieves may fit within that frame.  In that case, DMARC
intelligence services would highlight such data as appropriate.


> I'm happy to discuss alternative methods, but please bear in mind that for 
> this
> data alone we average around 80 connections/sec with peaks much higher than
> this, so adding in additional DNS lookups is costly.


Of course, DMARC records have to be looked up.  That is going to cost up to
three queries per domain...



Best
Ale
-- 































___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Rob McEwen via mailop]

On 3/22/2020 4:41 PM, Chris via mailop wrote:

It's been my experience that MOST of them are going to be red-herrings



+1

2 days ago, I got one of these for a domain for which I host email. I 
checked the SHA-1 hash against the current password's SHA-1 hash, and it 
didn't match. So it seemed like a complete waste of my time. I suspect 
that the vast majority of such intercepts... are going to be situations 
just like that - old passwords that were already changed years ago. I 
vaguely recall this users' account getting hacked several years ago, and 
the problem being fixed way back then. I don't like my time wasted 
trying to fix already-fixed problems.


--
Rob McEwen



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Chris via mailop]

On 2020-03-22 16:20, Nick Stallman via mailop wrote:
I got one of these the other day and I'm scratching my head about it as 
what's in the report cannot possibly be correct.


The report was for a domain we host the website for, but the domain has 
no email at all.
The account referenced is also not a valid website login or anything 
else I can think of.


It's not terribly useful if I'm going to be getting red herrings like that.


It's been my experience that MOST of them are going to be red-herrings. 
 I've seen a whole pile of such forged addresses with userids/passwords 
that I knew were completely impossible.


Imagine how useful it's going to be if you have a lot of spamtraps.  I 
mean, a *LOT* of spamtraps.


There's a reason why we're not doing the same thing.

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Nick Stallman via mailop]

I got one of these the other day and I'm scratching my head about it as 
what's in the report cannot possibly be correct.


The report was for a domain we host the website for, but the domain has 
no email at all.
The account referenced is also not a valid website login or anything 
else I can think of.


It's not terribly useful if I'm going to be getting red herrings like that.

On 22/3/20 3:34 pm, Udeme Ukutt via mailop wrote:

I pinged someone there to take a look.

Udeme


On Sat, Mar 21, 2020 at 9:17 PM Ted Cooper via mailop 
mailto:mailop@mailop.org>> wrote:


Has anyone run into "Abusix" /potentially/ compromised account
notification emails before?

Their website "abusix.ai " looks to be about a
week old based on the age
of all of the articles. I would have guessed they'd have been
around for
longer and their name does ring a bell. Blog announcement on
Abusix.com
would indicate they launched Mar 2019.

They've sent us a report from "nore...@abusix.org
" to postmaster@ here
in some kind of misguided attempt to help us because "Over the last 24
hour period our traps have detected 1 potentially compromised accounts
on your domain."

In the CSV they attached, apparently the IP address 185.234.219.89
(Poland) attempted to send an email at 2020-03-19T17:59:03.000Z using
smtp auth credentials apparently from a domain hosted here. That IP
address is not at all related to any networks or servers for the
domain.

They do provide the first 5 characters of the sha1 of the password
that
IP address used. I know it used the wrong password because the account
in question does not have a password - it's an alias and not an
account.

Given the number of fraudulent auth attempts we all get every day with
wild and whacky unrelated usernames (I get hotmail & others
provided as
username), why would anyone think it was a good idea to send out
spam to
stop spam when it was clearly a fraudulent email that didn't even go
anywhere? If everyone sent out a spam notification when someone
abused a
domain we'd all be getting 10x fold increase in spam, all trying to be
"helpful".

They do ever so helpfully provide an "opt out" link. I am
scratching my
head as to think when I opted into such a service. /sarcasm.

My initial thought was to route their domains and IPs to /dev/null,
happy in the thought that I now get one less domain's spam.


___
mailop mailing list
mailop@mailop.org 
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

--
Nick Stallman
Technical Director
Email   n...@agentpoint.com 
Phone   02 8039 6820 
Website www.agentpoint.com.au 


Agentpoint 
Netpoint 

67 Renwick St, Redfern NSW 2009 	Facebook 
 Twitter 
 Instagram 
 Linkedin 



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Bill Cole via mailop]

On 22 Mar 2020, at 10:28, Steve Freegard via mailop wrote:


Abuse reports shouldn't have to be opt-in.


True, but these are not abuse reports to an empowered party, but rather 
to possible victims.


It's akin to the FUSSPs that use mail-based challenge/response models or 
to SMTP callback verification.




I didn't design this to annoy people,


As designed, it will intrinsically annoy people who in no way deserve 
the annoyance or can benefit from it.



I did it because it's useful for the internet in general


It is not. It is a response to an Internet-wide problem, but it is not 
broadly useful.



because compromised accounts are a huge issue,


Yes, they are. This particular response does not generally improve mail 
system operators' capacity to mitigate that issue. The core reason that 
compromised accounts have increased as a problem is that users have 
gotten used to using the same email address and password everywhere  for 
authentication. This response does not address that in any way or help 
anyone receiving reports address it.


and one that causes issues for blacklist providers like us (e.g. if 
the compromised accounts are on unblockable IPs, then we have less 
ability to stop them), so this was more about providing data that 
previously wasn't available *for free* to help the community in 
general.


My mail logs and sometimes mailboxes are filled with essentially the 
same data for free in the form of backscatter. I can get a pretty good 
list of what email addresses in my domains are being shopped around at 
HIBP. I've mostly eliminated even logging of credential-stuffers by 
dropping their crap at the border, a thing that many small mail system 
operators can do. Even the data on such activity I can look at is mostly 
useless to me because it is overwhelmingly for single-purpose addresses, 
role accounts, or other sorts of non-authenticating aliases.


I really don't need or want more unrequested "free information 
customized for your needs" by people who clearly do not understand my 
needs and whom I am reluctant to generally shun. This should be like a 
FBL: a great idea for people who can actually use it, but not something 
you want to impose on everyone who might be able to use it.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Atro Tossavainen via mailop]

Steve,

> >I am not impressed.
> 
> Sorry about that Atro.

Having witnessed what I have today, I have to say I think your concept
is inherently flawed.

Also, my handful-of-dozen spams of this type are apparently a drop in
the ocean when compared to some of the more serious spamtrappers who
claim to have received thousands of the same.

> Obviously trap domains, due to the very nature of them are more
> likely to be abused in this way and I will do what I can next week
> to address this and exclude them from reporting.

You'll have an interesting time trying to figure out what to exclude.

> I've already found that SORBS and Manitu don't treat Abuse and
> Postmaster role accounts differently.

I can't speak for either. Koli-Lõks OÜ spamtraps do not directly feed
a blocklist, as well.

Personally I think the possibility for misfiring is way too great for
this concept to continue existing at all. Especially if you also send
automated reports to the hosting provider of the domain, which I think
I read in the message.

Abusix have quite a bit of credibility in the field, so I am fully
expecting to have at least some of our spamtrap servers suspended by
the various providers we use because of "potential abuse" you have
flagged on domains that don't contain any credentials that could be
abused and therefore have nothing to worry about. I take it you will
not have a problem with us sending Abusix a bill for any time wasted
dealing with problems that don't exist should that happen.

My advice to you is to off the damn thing about 48 hours ago.


> Kind regards,
> Steve.
> 
> --
> Steve Freegard
> Senior Product Owner
> Abusix Intelligence
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

-- 
Atro Tossavainen, Founder, Partner
Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635)
Tallinn, Estonia
tel. +372-5883-4269, http://www.koliloks.eu/

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Steve Freegard via mailop]

Hi Andrew,

On 22/03/2020 16:05, Andrew C Aitchison wrote:


On Sun, 22 Mar 2020, Steve Freegard via mailop wrote:
I didn't design this to annoy people, I did it because it's useful 
for the internet in general because compromised accounts are a huge 
issue, and one that causes issues for blacklist providers like us 
(e.g. if the compromised accounts are on unblockable IPs, then we 
have less ability to stop them), so this was more about providing 
data that previously wasn't available *for free* to help the 
community in general.


Is it possible, and/or useful, to reuse the DMARC reporting mechanism ?



I didn't do this because I figured that postmaster@ was the most 
appropriate place, and because many places will use service like 
DMARCian, Agari etc. for aggregate reports and it would mean that they'd 
be less likely to be seen if I sent them there.


I'm happy to discuss alternative methods, but please bear in mind that 
for this data alone we average around 80 connections/sec with peaks much 
higher than this, so adding in additional DNS lookups is costly.


The sheer amount of bounces from domains that don't have working 
postmaster@ accounts is a bit disheartening already.


Kind regards,
Steve.

--
Steve Freegard
Senior Product Owner
Abusix Intelligence

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Andrew C Aitchison via mailop]

On Sun, 22 Mar 2020, Steve Freegard via mailop wrote:

This data is inherently noisy and I've gone to extreme lengths 
to remove as much noise as possible and provide Abuse 
Desks/Postmasters some visibility that they do not currently 
have.


Whilst this time it's reported an alias, next time it might 
catch an account that was successfully phished, stolen by a 
trojan/virus on the users computer or where another company 
had a data breach and the user had the same password on that 
service.



Abuse reports shouldn't have to be opt-in.

I didn't design this to annoy people, I did it because it's 
useful for the internet in general because compromised 
accounts are a huge issue, and one that causes issues for 
blacklist providers like us (e.g. if the compromised accounts 
are on unblockable IPs, then we have less ability to stop 
them), so this was more about providing data that previously 
wasn't available *for free* to help the community in general.


Is it possible, and/or useful, to reuse the DMARC reporting mechanism ?

--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Steve Freegard via mailop]

Hi Atro,

On 22/03/2020 11:23, Atro Tossavainen via mailop wrote:

On Sun, Mar 22, 2020 at 02:11:45PM +1000, Ted Cooper via mailop wrote:

Has anyone run into "Abusix" /potentially/ compromised account
notification emails before?

Not before, but now that you say, yes.

I have a few dozen samples in spamtraps from Friday Mar 20, never before.
They're both in recycled traps as well as in typo ones. They are coming
from the IPs 88.99.195.122, 88.99.167.62, 85.10.192.252, all of which
have the same rDNS

$ host 88.99.167.62
62.167.99.88.in-addr.arpa domain name pointer globalreport.abusix.org.

which maps back to the addresses involved

$ host globalreport.abusix.org
globalreport.abusix.org has address 88.99.195.122
globalreport.abusix.org has address 88.99.167.62
globalreport.abusix.org has address 85.10.192.252

I am not impressed.


Sorry about that Atro.

Obviously trap domains, due to the very nature of them are more likely 
to be abused in this way and I will do what I can next week to address 
this and exclude them from reporting.


I've already found that SORBS and Manitu don't treat Abuse and 
Postmaster role accounts differently.


Kind regards,
Steve.

--
Steve Freegard
Senior Product Owner
Abusix Intelligence

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Steve Freegard via mailop]

Hi Thomas,

On 22/03/2020 09:03, Thomas Walter via mailop wrote:


I got the same email with some of our local accounts and aliases.
Interestingly enough it included the same IP address 185.234.219.89.


That will happen, one IP usually goes absolutely crazy and sends most of 
the traffic, other times we'll see this distributed over a lot of 
different IPs.




Checking my logs I have multiple failed logins from the address
including the accounts they listed, but some more too.


We won't always report everything, we're only reporting accounts that we 
haven't seen before in the last 31 days (to avoid too much unnecessary 
noise).  So we might have already seen those accounts or they came in 
after that days report was generated.



I wonder what kind of "Spamtraps" they use and why the attacker uses our
local accounts to fall into those?




I'm sure you'll understand that I can't really say on a public forum how 
we do this.   Catch me at a M3AAWG or other event and I'll give you more 
details.


Kind regards,
Steve.

--
Steve Freegard
Senior Product Owner
Abusix Intelligence

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Steve Freegard via mailop]

Hi Luis,

On 22/03/2020 04:59, Luis E. Muñoz via mailop wrote:


I got three in the last 48 hours at different sites. All referenced 
real user accounts – no clue about the password. The warning seemed 
legit so I passed the info to the potentially affected users, with the 
recommendation to change their passwords at any sites where they used 
said email accounts.




Thank you - that is *exactly* how I'd hoped this would be used.

I put the partial SHA-1 in so that it could be used with 
www.haveibeenpwned.com as they use the same format for good reasons, so 
it should work with any compatible tooling and automation.



My reading is that bad actors will find valid email addresses as part 
of successful exploits and then feed those into their automated attacks.




They'll get these via database dumps, compromised hosts and phishing.

Kind regards,
Steve.

--
Steve Freegard
Senior Product Owner
Abusix Intelligence

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Steve Freegard via mailop]

Hello Ted,

On 22/03/2020 04:11, Ted Cooper via mailop wrote:

Has anyone run into "Abusix" /potentially/ compromised account
notification emails before?

Their website "abusix.ai" looks to be about a week old based on the age
of all of the articles. I would have guessed they'd have been around for
longer and their name does ring a bell. Blog announcement on Abusix.com
would indicate they launched Mar 2019.


Abusix has been in existence since 2009, although Abusix Intelligence 
which I am the Product Owner/Architect has existed since I joined Abusix 
in January 2019.



They've sent us a report from "nore...@abusix.org" to postmaster@ here
in some kind of misguided attempt to help us because "Over the last 24
hour period our traps have detected 1 potentially compromised accounts
on your domain."

In the CSV they attached, apparently the IP address 185.234.219.89
(Poland) attempted to send an email at 2020-03-19T17:59:03.000Z using
smtp auth credentials apparently from a domain hosted here. That IP
address is not at all related to any networks or servers for the domain.


The IP reported here is the IP that authenticated to us and sent the 
credentials which were on your domain, so it's (hopefully!) never going 
to be related to you.



They do provide the first 5 characters of the sha1 of the password that
IP address used. I know it used the wrong password because the account
in question does not have a password - it's an alias and not an account.

Given the number of fraudulent auth attempts we all get every day with
wild and whacky unrelated usernames (I get hotmail & others provided as
username), why would anyone think it was a good idea to send out spam to
stop spam when it was clearly a fraudulent email that didn't even go
anywhere? If everyone sent out a spam notification when someone abused a
domain we'd all be getting 10x fold increase in spam, all trying to be
"helpful".


It's not about reporting every individual spam though is it, that's a 
completely different scenario entirely.


Like you say, you receive thousands of fraudulent authentication 
attempts per day and we've reported *one* to you in this report, I can 
guarantee you we saw the same thousands that you did and discarded them 
because we'd seen them before.   Likewise, this particular account will 
not be reported to you again until we stop seeing it for >31 days.


This data is inherently noisy and I've gone to extreme lengths to remove 
as much noise as possible and provide Abuse Desks/Postmasters some 
visibility that they do not currently have.


Whilst this time it's reported an alias, next time it might catch an 
account that was successfully phished, stolen by a trojan/virus on the 
users computer or where another company had a data breach and the user 
had the same password on that service.



They do ever so helpfully provide an "opt out" link. I am scratching my
head as to think when I opted into such a service. /sarcasm.

My initial thought was to route their domains and IPs to /dev/null,
happy in the thought that I now get one less domain's spam.



Abuse reports shouldn't have to be opt-in.

I didn't design this to annoy people, I did it because it's useful for 
the internet in general because compromised accounts are a huge issue, 
and one that causes issues for blacklist providers like us (e.g. if the 
compromised accounts are on unblockable IPs, then we have less ability 
to stop them), so this was more about providing data that previously 
wasn't available *for free* to help the community in general.


Kind regards,
Steve.

--
Steve Freegard
Senior Product Owner
Abusix Intelligence

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Atro Tossavainen via mailop]

On Sun, Mar 22, 2020 at 02:11:45PM +1000, Ted Cooper via mailop wrote:
> Has anyone run into "Abusix" /potentially/ compromised account
> notification emails before?

Not before, but now that you say, yes.

I have a few dozen samples in spamtraps from Friday Mar 20, never before.
They're both in recycled traps as well as in typo ones. They are coming
from the IPs 88.99.195.122, 88.99.167.62, 85.10.192.252, all of which
have the same rDNS

$ host 88.99.167.62
62.167.99.88.in-addr.arpa domain name pointer globalreport.abusix.org.

which maps back to the addresses involved

$ host globalreport.abusix.org
globalreport.abusix.org has address 88.99.195.122
globalreport.abusix.org has address 88.99.167.62
globalreport.abusix.org has address 85.10.192.252

I am not impressed.

Full disclosure: If I'm really optimistic, I would call our little company
a competitor of theirs, even though their volume is probably a million
times that of ours. I also know Tobias Knecht personally, as do many of
you all on this list, of course. I did notice that Udeme had already
pinged someone, him I suppose, but I did the same now, with all of this
detail.

Mit freundlichen Grüssen
-- 
Atro Tossavainen, Founder, Partner
Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635)
Tallinn, Estonia
tel. +372-5883-4269, http://www.koliloks.eu/

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Thomas Walter via mailop]

Hey everyone,

On 22.03.20 05:11, Ted Cooper via mailop wrote:
> Has anyone run into "Abusix" /potentially/ compromised account
> notification emails before?

I got the same email with some of our local accounts and aliases.
Interestingly enough it included the same IP address 185.234.219.89.

Checking my logs I have multiple failed logins from the address
including the accounts they listed, but some more too.

I wonder what kind of "Spamtraps" they use and why the attacker uses our
local accounts to fall into those?

Regards,
Thomas Walter

-- 
Thomas Walter
Datenverarbeitungszentrale

FH Münster
- University of Applied Sciences -
Corrensstr. 25, Raum B 112
48149 Münster

Tel: +49 251 83 64 908
Fax: +49 251 83 64 910
www.fh-muenster.de/dvz/

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Luis E. Muñoz via mailop]

On 21 Mar 2020, at 21:11, Ted Cooper via mailop wrote:


Has anyone run into "Abusix" /potentially/ compromised account
notification emails before?


I got three in the last 48 hours at different sites. All referenced real 
user accounts – no clue about the password. The warning seemed legit 
so I passed the info to the potentially affected users, with the 
recommendation to change their passwords at any sites where they used 
said email accounts.


My reading is that bad actors will find valid email addresses as part of 
successful exploits and then feed those into their automated attacks.


Best regards

-lem

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Abusix Potentially Compromised Account Report

[Udeme Ukutt via mailop]

I pinged someone there to take a look.

Udeme


On Sat, Mar 21, 2020 at 9:17 PM Ted Cooper via mailop 
wrote:

> Has anyone run into "Abusix" /potentially/ compromised account
> notification emails before?
>
> Their website "abusix.ai" looks to be about a week old based on the age
> of all of the articles. I would have guessed they'd have been around for
> longer and their name does ring a bell. Blog announcement on Abusix.com
> would indicate they launched Mar 2019.
>
> They've sent us a report from "nore...@abusix.org" to postmaster@ here
> in some kind of misguided attempt to help us because "Over the last 24
> hour period our traps have detected 1 potentially compromised accounts
> on your domain."
>
> In the CSV they attached, apparently the IP address 185.234.219.89
> (Poland) attempted to send an email at 2020-03-19T17:59:03.000Z using
> smtp auth credentials apparently from a domain hosted here. That IP
> address is not at all related to any networks or servers for the domain.
>
> They do provide the first 5 characters of the sha1 of the password that
> IP address used. I know it used the wrong password because the account
> in question does not have a password - it's an alias and not an account.
>
> Given the number of fraudulent auth attempts we all get every day with
> wild and whacky unrelated usernames (I get hotmail & others provided as
> username), why would anyone think it was a good idea to send out spam to
> stop spam when it was clearly a fraudulent email that didn't even go
> anywhere? If everyone sent out a spam notification when someone abused a
> domain we'd all be getting 10x fold increase in spam, all trying to be
> "helpful".
>
> They do ever so helpfully provide an "opt out" link. I am scratching my
> head as to think when I opted into such a service. /sarcasm.
>
> My initial thought was to route their domains and IPs to /dev/null,
> happy in the thought that I now get one less domain's spam.
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop